Draft -05 of the Authentication Method Reference Values specification addresses the IETF last call comments received. Changes were:
amr” values, reusing the IANA Considerations language on this topic from RFC 7638.Thanks to Linda Dunbar, Catherine Meadows, and Paul Kyzivat for their reviews.
The specification is available at:
An HTML-formatted version is also available at:
The IETF OAuth working group decided at IETF 97 to proceed with standardizing the OAuth Authorization Server Metadata specification, which is already in widespread use, and to stop work on the OAuth Protected Resource Metadata specification, which is more speculative. Accordingly, a new version of the AS Metadata spec has been published that removes its dependencies upon the Resource Metadata spec. In particular, the “protected_resources” AS Metadata element has been removed. Its definition has been moved to the Resource Metadata spec for archival purposes. Note that the Resource Metadata specification authors intend to let it expire unless the working group decides to resume work on it at some point in the future.
The specifications are available at:
HTML-formatted versions are also available at:
The CBOR Web Token (CWT) specification now registers the “application/cwt” media type, which accompanies the existing CoAP Content-Format ID registration for this media type. The description of nested CWTs, which uses this content type, was clarified. This draft also corrected some nits identified by Ludwig Seitz.
The specification is available at:
An HTML-formatted version is also available at:
The specification Using RSA Algorithms with COSE Messages defines encodings for using RSA algorithms with CBOR Object Signing and Encryption (COSE) messages. This supports use cases for the FIDO Alliance and others that need this functionality. Security Area Director Kathleen Moriarty has agreed to AD sponsorship of this specification. This specification incorporates text from draft-ietf-cose-msg-05 — the last COSE specification version before the RSA algorithms were removed.
The specification is available at:
An HTML-formatted version is also available at:
Review feedback is welcomed!
As those of you who have been following the id-event@ietf.org mailing list or attended the inaugural meeting of the new IETF Security Events working group know, Phil Hunt and co-authors (including myself) have been working on a Security Event Token (SET) specification. A SET is a JSON Web Token (JWT) with an “events” claim that contains one or more event identifiers (which are URIs) that say what event the SET describes.
This work isn’t being done in isolation. Among others, the OpenID Risk and Incident Sharing and Coordination (RISC) working group, the OpenID Back-Channel Logout specification, and the SCIM Provisioning Events work intend to use the Security Event Token format.
To make this concrete, the claims in an example OpenID Connect Back-Channel Logout token (which is a SET) are:
{
"iss": "https://server.example.com",
"sub": "248289761001",
"aud": "s6BhdRkqt3",
"iat": 1471566154,
"jti": "bWJq",
"sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
"events": {
"http://schemas.openid.net/event/backchannel-logout": {}
}
}
You’ll see that this a normal JWT, with the issuer, subject, and session ID identifying the target of the logout, and the “events” value identifying the JWT as a logout SET.
Today, we published an updated SET spec based on discussions at IETF 97, which simplifies the SET parsing. Thanks to Phil Hunt or Oracle, William Denniss of Google, Morteza Ansari of Cisco, and the numerous other contributors who’ve gotten us to this point. We now believe that this specification is ready for adoption by the Security Events working group.
The specification is available at:
An HTML-formatted version is also available at:
The OpenID Connect Back-Channel Logout specification should be updated soon (after the US Thanksgiving holiday) to utilize the simplified SET syntax. Happy Thanksgiving, everyone!
Draft -04 of the Authentication Method Reference Values specification addresses comments by our security area director Kathleen Moriarty. Changes were:
amr” claim examples with both single and multiple values.The specification is available at:
An HTML-formatted version is also available at:
Draft -03 of the Authentication Method Reference Values specification addresses the shepherd comments. It changes the references providing information about specific “amr” values to be informative, rather than normative. A reference to ISO/IEC 29115 was also added. No normative changes were made.
The specification is available at:
An HTML-formatted version is also available at:
The OAuth Token Binding specification has been revised to use the Referred Token Binding ID when performing token binding of access tokens. This was enabled by the Implementation Considerations in the Token Binding HTTPS specification being added to make it clear that Token Binding implementations will enable using the Referred Token Binding ID in this manner. Protected Resource Metadata was also defined.
Thanks to Brian Campbell for clarifications on the differences between token binding of access tokens issued from the authorization endpoint versus those issued from the token endpoint.
The specification is available at:
An HTML-formatted version is also available at:
Draft -02 of the Authentication Method Reference Values specification addresses the Working Group Last Call (WGLC) comments received. It adds an example to the multiple-channel authentication description and moves the “amr” definition into the introduction. No normative changes were made.
The specification is available at:
An HTML-formatted version is also available at:
The initial working group draft of the OAuth Token Binding specification has been published. It has the same content as draft-jones-oauth-token-binding-00, but with updated references. This specification defines how to perform token binding for OAuth access tokens and refresh tokens. Note that the access token mechanism is expected to change shortly to use the Referred Token Binding, per working group discussions at IETF 96 in Berlin.
The specification is available at:
An HTML-formatted version is also available at:
The W3C Web Authentication working group has announced publication of the second public draft of the W3C Web Authentication specification. The working group expects to be issuing more frequent working drafts as we approach a Candidate Recommendation.
Session ID definitions in the OpenID Connect front-channel and back-channel logout specs have been aligned so that the Session ID definition is now the same in both specs. The Session ID is scoped to the Issuer in both specs now (whereas it was previously global in scope in the front-channel spec). This means that the issuer value now needs to be supplied whenever the Session ID is. This doesn’t change the simple (no-parameter) front-channel logout messages. The back-channel specification is now also aligned with the ID Event Token specification.
The new specification versions are:
The OpenID Enhanced Authentication Profile (EAP) working group was created to enable use of the IETF Token Binding specifications with OpenID Connect and to enable integration with FIDO relying parties and/or other strong authentication technologies. The OpenID Foundation has now published the initial EAP specifications as a first step towards accomplishing these goals. See the announcement on openid.net.
The existing OAuth 2.0 Authorization Server Metadata specification has now been joined by a related OAuth 2.0 Protected Resource Metadata specification. This means that JSON metadata formats are now defined for all the OAuth 2.0 parties: clients, authorization servers, and protected resources.
The most significant addition to the OAuth 2.0 Authorization Server Metadata specification is enabling signed metadata, represented as claims in a JSON Web Token (JWT). This is analogous to the role that the Software Statement plays in OAuth Dynamic Client Registration. Signed metadata can also be used for protected resource metadata.
For use cases in which the set of protected resources used with an authorization server are enumerable, the authorization server metadata specification now defines the “protected_resources” metadata value to list them. Likewise, the protected resource metadata specification defines an “authorization_servers” metadata value to list the authorization servers that can be used with a protected resource, for use cases in which those are enumerable.
The specifications are available at:
HTML-formatted versions are also available at:
This draft distinguishes between iris and retina scan biometrics, as requested by NIST, and adds a paragraph providing readers more context at the end of the introduction, which was requested by the chairs during the call for adoption. The OpenID Connect MODRNA Authentication Profile 1.0 specification, which uses “amr” values defined by this specification, is now also referenced.
The specification is available at:
An HTML formatted version is also available at:
The OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 specification has been submitted to the OpenID Enhanced Authentication Profile (EAP) working group. Per the abstract:
This specification enables OpenID Connect Relying Parties to request that specific authentication context classes be applied to authentications performed and for OpenID Providers to inform Relying Parties whether these requests were satisfied. Specifically, an authentication context class reference value is defined that requests that phishing-resistant authentication be performed and another is defined that requests that phishing-resistant authentication with a hardware-protected key be performed. These policies can be satisfied, for instance, by using W3C scoped credentials or FIDO authenticators.
The specification is glue that ties together OpenID Connect, W3C Web Authentication, and FIDO Authenticators, enabling them to be seamlessly used together.
The specification is available at:
The only change to the new draft is to use terminology more consistently. Specifically, it changes the terms “issuer URL” and “configuration information location” to “issuer identifier” so that consistent terminology is used for this. (This is the terminology used by OpenID Connect.)
This is being posted in preparation for discussions at the upcoming OAuth Security Workshop in Trier, Germany and the IETF 96 meeting in Berlin.
The specification is available at:
An HTML-formatted version is also available at:
The CBOR Web Token (CWT) specification now establishes the IANA CWT Claims registry and registers the CWT claims defined by the specification. The application/cwt CoAP content type is now also registered.
This version adds Samuel Erdtman as an editor in recognition of his already significant contributions to the specification.
The specification is available at:
An HTML-formatted version is also available at:
Two new related specifications define syntax and semantics for applying Token Binding to OAuth Access Tokens and Refresh Tokens and to OpenID Connect ID Tokens. draft-jones-oauth-token-binding contains the OAuth portions. openid-connect-token-bound-authentication-1_0 contains the OpenID Connect portions.
These are being submitted now to hopefully enable end-to-end implementations and interop testing of Token Bound Access Tokens, Refresh Tokens, and ID Tokens across multiple platforms before the Token Binding specifications are finalized.
The OAuth specification is available at:
The OpenID Connect specification is available at:
Thanks to Andrei Popov, Yordan Rouskov, John Bradley, and Brian Campbell for reviews of earlier versions of these specifications and to Dirk Balfanz and William Denniss for some earlier discussions providing input to these specifications.
The W3C Web Authentication Working Group today announced publication of the First Public Working Draft of the W3C Web Authentication specification. The abstract of the specification is:
This specification defines an API that enables web pages to access WebAuthn compliant strong cryptographic credentials through browser script. Conceptually, one or more credentials are stored on an authenticator, and each credential is scoped to a single Relying Party. Authenticators are responsible for ensuring that no operation is performed without the user’s consent. The user agent mediates access to credentials in order to preserve user privacy. Authenticators use attestation to provide cryptographic proof of their properties to the relying party. This specification also describes a functional model of a WebAuthn compliant authenticator, including its signature and attestation functionality.
This specification is derived from the November 12, 2015 member submission of FIDO 2.0 Platform Specifications. Content from the three submitted specifications has been merged into a single Web Authentication specification, also incorporating changes agreed to by the Web Authentication working group. The working group intends to continue making timely progress, planning to publish a Candidate Recommendation by September 2016.
Powered by WordPress & Theme by Anders Norén