Cross-posted from the Oracle Fusion Middleware Blog.
As many of you know, much of today's standards around REST center around IETF based specifications. As such, I thought I would share some RESTful services related news coming from last week's IETF meetings. Many working groups are now in the final stages of moving key specifications into standard status…JSON
A new standard draft for JSON (RFC 7159) was announced that replaces RFC4627. This specification isn't a major change but clarifies some confusing issues in the original JSON specification. Tim Bray, one of the specification's authors has a good write-up here on the need for a new specification and what it covers.
OAuth2 HoK Tokens - Informal Meeting
An extended informal working session was held on Sunday on Holder-of-Key and Message Authentication tokens for OAuth2. The overall model between clients, authorization servers, and how clients access resources was enhanced due to an expansion in use cases and security concerns that have evolved over the past year. As an aside, I heard a lot of hallway talk about new requirements emerging for non-web protocols where there is a huge desire to get rid of the username/passwords anti-pattern in lots of other protocols such SMTP/IMAP, XMPP or for that matter any classic single factor app from the past.OpenID Connect Meeting
The OpenID Foundation had an on-site OpenID Connect meeting on Sunday. They announced and reviewed the final draft of OpenID Connect. A partnership with GSMA (mobile alliance) was also announced that will profile Connect to allow mobile phone users to use their mobile phone carrier accounts as login providers for web services and social networks.JOSE
JOSE is a working group developing specifications for how to do signing and encryption of JSON objects. The working group drafts have completed the "last call" review process and are now going to the IESG for publication. This work is finally nearing RFC status!
Matt Miller has started work on a cookbook. - JOSE Cookbook. This draft promises to be a useful tool for figuring out all the cool ways signing and encryption can be combined to serve many different purposes.
The OAuth2 Assertion Draft and OAuth2 SAML2 Bearer Drafts and the JWT Bearer Draft will all go forward to IESG for final approval. These drafts describe how JWT and SAML2 assertions can be used as OAuth Client authentication assertions and as OAuth2 Authorization Grant Assertions. These drafts are often used when federating an authorization assertions between domains and for bridging authorizations between SAML2 and OAuth infrastructures.
In OAuth2 if you are building a client application meant to work against multiple service providers of the same API you have probably run into the question of how to obtain a "client_id" that will be accepted by the different service providers. Dynamic registration is the specification that answers this problem. This work may turn out to be even more useful when you start to consider clients like imap/smtp clients that work with many different user-configured email service providers. The working group determined that the main core registration drafts are now reaching maturity, but there is still much discussion on the ability of clients to update and manage their registrations through a "management API".
OAuth 2
The JSON Web Token draft describes a token format usable with OAuth2 and other protocols. JWT is now ready to go to the IESG for approval pending approval of the JOSE specifications upon which it depends.The OAuth2 Assertion Draft and OAuth2 SAML2 Bearer Drafts and the JWT Bearer Draft will all go forward to IESG for final approval. These drafts describe how JWT and SAML2 assertions can be used as OAuth Client authentication assertions and as OAuth2 Authorization Grant Assertions. These drafts are often used when federating an authorization assertions between domains and for bridging authorizations between SAML2 and OAuth infrastructures.
In OAuth2 if you are building a client application meant to work against multiple service providers of the same API you have probably run into the question of how to obtain a "client_id" that will be accepted by the different service providers. Dynamic registration is the specification that answers this problem. This work may turn out to be even more useful when you start to consider clients like imap/smtp clients that work with many different user-configured email service providers. The working group determined that the main core registration drafts are now reaching maturity, but there is still much discussion on the ability of clients to update and manage their registrations through a "management API".
ACE BoF (Authorization for Internet of Things)
ACE or Authorizing for Constrained Environments is a new workgroup that the IETF is considering forming which will address authorization requirements for the Internet of Things (IoT). Where the Internet began by connecting "places", it quickly moved to connecting people (billions of phones) and in the near future, 50 billion "things" - highlighting a key concern for scale in the future. And while the Internet must "scale up" to this need, at the same time, technology must "scale down" to support "constrained" devices.What is a constrained device? A constrained device is one that is severely limited by processor, power, and memory. For servers and laptops we've been used to exploiting Moore's Law to gain increasing processing power at lower-costs. While for constrained devices, lower-power consumption and lower chip costs are prioritized at the expense of processing power. Some of you may already be familiar with the Nest heating control and the Fitbit, but IoT goes much deeper into items like tracking monitors for shipping containers to industrial manufacturing sensors and actuators that collect billions of data points and run production control systems, to building environmental and security systems. As these items are moved onto the Internet, a new authorization and security standard is needed.
One of the characteristics of constrained devices is that they often use UDP internet protocol rather than the Web's familiar TCP internet protocol. ACE is building on a lot of existing work from the IETF to address this issue. For constrained devices there is already a series of parallel of specifications to support RESTful services:
- CoAP (Constrained Access Protocol) which is essentially HTTP over UDP
- DTLS (RFC6347) which is Datagram TLS (over UDP)
- CoRE == Constrained REST set of specifications
Some example use cases might include:
- Cargo container tracking an control
- Home automation
- Manufacturing control and monitoring systems (from my experience at Alcan this is BIG). Alcan uses sensors to pick up HUGE volumes of data for quality control and research purposes. Security has always been a big problem because of use of COM on DOS boxes.
- Building access and security
- Environmental controls
- Cloud based consumer devices like NEST, set top boxes, remote controls, etc
SCIM
The SCIM working group continued to refine the SCIM specifications by working through the list of outstanding issues (recently cutting them in half). The group also discussed a proposal on how the SCIM Patch operation might be simplified using the JSON Patch (RFC6902) specification. This would addressing long-standing concerns about the understandability of SCIM's existing patch command. The group worked through the rest of the outstanding items and is on track towards a final draft.For more details and meeting minutes for the IETF 89 meeting, click here.
No comments:
Post a Comment