Identity Standards: Year in Review
A lot has happened in the identity standards world over the last year. I cover some of the most exciting work in my session, Around the Identity World in 30 Minutes, but there is far too much to cover in a single session. Here I will describe some of the developments that didn’t make it into the talk, and provide links for deeper dives into those that did.
OpenID Connect Financial-grade API Security Profile 1.0
The OpenID Foundation has published the final draft of its Financial-grade API (FAPI) Security Profile 1.0, “a highly secured OAuth profile that aims to provide specific implementation guidelines for security and interoperability.” Despite the name, this profile is not particular to the finance industry, and may be applicable to any security-sensitive use case. It is divided into two parts. Part 1 defines a profile aimed at APIs with “moderate inherent risk”, while Part 2 defines one for APIs with “high inherent risk.”
OAuth 2.0: JWT Secured Authorization Requests (JAR)
JWT Secured Authorization Requests (JARs) JARs are JSON Web Tokens (JWTs) representing OAuth 2.0 authorization requests. The JAR draft defines the JAR representation, and a way to submit an OAuth 2.0 authorization request as a JAR embedded in the URL or referenced via a URI, instead of as plaintext query string parameters in a URL. JARs can be encrypted and/or signed, optionally providing confidentiality, authenticity, and integrity for request parameters. After 7 years of work, the JAR draft is in the final rounds of the IETF publishing process. Expect to see this as an RFC soon.
OAuth 2.0: Pushed Authorization Requests (PAR)
The Pushed Authorization Requests (PAR) draft defines an alternate way to protect the contents of for an OAuth 2.0 client to submit an authorization request directly to the authorization server and obtain an opaque identifier for that request, which can take the place of most of the parameters in the authorization request URL. Like JAR, this can be used to provide confidentiality, authenticity, and integrity for authorization request parameters. It can also allow clients to submit larger authorization requests, as they do not need to fit into a URL. PAR explicitly supports JAR, providing developers with a lot of flexibility. While not quite as far along as JAR, this draft is just a step or two behind the JAR draft, and should be published as an RFC relatively soon.
JWT Profile for OAuth 2.0 Access Tokens
This draft describes how to format OAuth 2.0 access tokens as JSON Web Tokens. This may be particularly interesting in deployments where the authorization server and resource servers are only loosely affiliated, or owned by completely separate entities, such as in larger organizations with centralized identity but distributed resource ownership, or broad identity federations.
JWT Response for OAuth 2.0 Token Introspection
Following the trend, this draft describes how to encode the response from the OAuth 2.0 Token Introspection endpoint (RFC 7662) as a JSON Web Token instead of as a plain JSON object. As with JAR, this allows the optional use of JWE and/or JWS to provide additional security properties for the response. While not quite as far along as the drafts mentioned above, this draft has been approved by the OAuth Working Group and is now undergoing IESG review.
Authentication and Authorization for Constrained Environments using OAuth 2.0 (ACE-OAuth)
ACE-OAuth profiles, extends, and adapts OAuth 2.0, the Constrained Application Protocol (CoAP), and other building blocks to create an authentication and authorization framework suitable for use with IoT devices. After 6 years and whole lot of revisions, ACE-OAuth is now steadily progressing through the IESG review process.
Push/Poll-Based Security Event Token (SET) Delivery Using HTTP
The IETF Security Events Working Group completed their work on a pair of specifications that define protocols for delivering Security Event Tokens (SETs): in the Push-Based protocol, SETs are delivered via requests from the transmitter to the receiver; in the Poll-Based protocol, the receiver retrieves SETs from an endpoint hosted by the transmitter. These protocols have been published as RFC 8935 and RFC 8936, respectively.
WebAuthn Level 2 and CTAP 2.1
The W3C has finalized WebAuthn Level 2 as a W3C Recommendation, and the FIDO Alliance has published CTAP 2.1 as a Proposed Standard. These are largely incremental improvements over WebAuthn Level 1 and CTAP 2. Notable new features include: support for usage within cross-origin iframes, improved attestation options for enterprises, and credential management for discoverable credentials. Looking ahead, the W3C has already begun work on WebAuthn Level 3.
Other Ongoing Work
The past year also saw introductions or updates to several other identity-related drafts:
- OpenID Connect Front-Channel Logout 1.0, Back-Channel Logout 1.0, and Session Management 1.0
- OpenID Connect Federation 1.0
- OAuth 2.0 Authorization Server Identifier in Authorization Response
- OAuth 2.0 Rich Authorization Requests (RAR)
- Subject Identifiers for Security Event Tokens
- Decentralized Identifiers (DIDs) v1.0
Finally, for those interested in learning more about the topics covered in the session:
- OAuth 2.0 Security Best Current Practices
- The OAuth 2.1 Authorization Protocol
- OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)
- Signing HTTP Messages
- Grant Negotiation and Authorization Protocol
- OpenID Connect Shared Signals and Events Framework
- WebID Explainer