Draft -07 of the JWS Unencoded Payload Option specification addresses Gen-Art review comments by Robert Sparks and Sec-Dir review comments by Benjamin Kaduk. Thanks to both of you for your useful reviews!
The specification is available at:
An HTML-formatted version is also available at:
After input from many interested people, IETF Security Area Director Kathleen Moriarty decided that the right place for the CBOR Web Token (CWT) work is the ACE working group. Today Erik Wahlström posted a new draft of the CBOR Web Token (CWT) specification that is intended for ACE.
This version of the spec references the JSON Web Token (JWT) claim definitions, rather than repeating them, and intentionally only includes equivalents of the claims defined by the JWT spec. Other CWT claims, including those needed by ACE applications, will be defined by other specs and registered in the CWT claims registry.
The specification is available at:
An HTML-formatted version is also available at:
Authentication Method Reference Values draft -03 adds the criterion to the IANA registration instructions that the value being registered be in actual use.
The specification is available at:
An HTML formatted version is also available at:
Proof-of-Possession Key Semantics for JWTs draft -08 addresses additional Area Director review comments. A security consideration about utilizing audience restriction in combination with proof-of-possession was added. Thanks to John Bradley for working on the additional wording with me.
The specification is available at:
An HTML formatted version is also available at:
I’m pleased to announce that Nat Sakimura, John Bradley, and I have created an OAuth 2.0 Discovery specification. This fills a hole in the current OAuth specification set that is necessary to achieve interoperability. Indeed, the Interoperability section of OAuth 2.0 states:
In addition, this specification leaves a few required components partially or fully undefined (e.g., client registration, authorization server capabilities, endpoint discovery). Without these components, clients must be manually and specifically configured against a specific authorization server and resource server in order to interoperate.
This framework was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.
This specification enables discovery of both endpoint locations and authorization server capabilities.
This specification is based upon the already widely deployed OpenID Connect Discovery 1.0 specification and is compatible with it, by design. The OAuth Discovery spec removes the portions of OpenID Connect Discovery that are OpenID specific and adds metadata values for Revocation and Introspection endpoints. It also maps OpenID concepts, such as OpenID Provider, Relying Party, End-User, and Issuer to their OAuth underpinnings, respectively Authorization Server, Client, Resource Owner, and the newly introduced Configuration Information Location. Some identifiers with names that appear to be OpenID specific were retained for compatibility purposes; despite the reuse of these identifiers that appear to be OpenID specific, their usage in this specification is actually referring to general OAuth 2.0 features that are not specific to OpenID Connect.
The specification is available at:
An HTML-formatted version is also available at:
Proof-of-Possession Key Semantics for JWTs draft -07 addresses review comments by our Area Director, Kathleen Moriarty, as well as comments by Hannes Tschofenig and Justin Richer. This should hopefully enable IETF last call.
The specification is available at:
An HTML formatted version is also available at:
Draft -06 of the JWS Unencoded Payload Option specification addresses review comments by our Area Director, Kathleen Moriarty. This should hopefully enable IETF last call.
The specification is available at:
An HTML formatted version is also available at:
Draft -05 of the JWS Unencoded Payload Option specification reworked the security considerations text on preventing confusion between encoded and unencoded payloads.
The specification is available at:
An HTML formatted version is also available at:
I know that some of you have been following the IETF’s work on the CBOR Object Signing and Encryption (COSE) Working group on creating a Concise Binary Object Representation (CBOR) equivalent of the JSON-based cryptographic data formats produced by the JSON Object Signing and Encryption (JOSE) Working group. I’m happy to announce that work has now started on a CBOR Web Token (CWT) specification: a CBOR mapping of the JSON Web Token (JWT) security token format that was built using the JOSE specifications. While I expect JSON and the JOSE/JWT specs to continue be used in most Web, PC, phone, tablet, cloud, and enterprise contexts, the COSE specs and now CWT are designed for use in constrained environments, such as those for some Internet of Things (IoT) devices.
Just as it was important to have a JSON-based security token format for applications using JSON, it will be important to have a CBOR-based security token format for applications using CBOR. CBOR Web Token (CWT) fills that role. Note that what is actually defined is a general cryptographically secured CBOR data structure, enabling CWTs to be used as general application payloads for CBOR-based applications.
The abstract of the specification is:
CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. CWT is a profile of the JSON Web Token (JWT) that is optimized for constrained devices. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value.
My thanks to Erik Wahlström and Hannes Tschofenig for helping to make this happen!
Finally, I’ll note that just as the suggested pronunciation of JWT is the same as the English word “jot”, the suggested pronunciation of CWT is the same as the English word “cot”. So welcome to “cots”!
The specification is available at:
An HTML formatted version is also available at:
Draft -04 of the JWS Unencoded Payload Option specification addresses the shepherd comments. Thanks to Jim Schaad for his careful review. The primary change was adding additional security considerations text, including describing when “crit” should be used.
The specification is available at:
An HTML formatted version is also available at:
Proof-of-Possession Key Semantics for JWTs draft -06 addresses the remaining document shepherd comment – adding use case diagrams to the introduction.
The updated specification is available at:
An HTML formatted version is also available at:
Proof-of-Possession Key Semantics for JWTs draft -05 addresses Kepeng Li’s document shepherd comments (other than adding some use case diagrams in the introduction, which will happen soon).
The updated specification is available at:
An HTML formatted version is also available at:
Draft -03 of the JWS Unencoded Payload Option specification addresses the working group last call comments received. Thanks to Jim Schaad, Vladimir Dzhuvinov, John Bradley, and Nat Sakimura for the useful comments. Changes were:
The specification is available at:
An HTML formatted version is also available at:
Draft -02 of the JWS Unencoded Payload Option specification makes these updates:
b64” be integrity protected.b64” Header Parameter value MUST be the same for all of them."b64":false.Thanks for the working group feedback that resulted in these improvements.
The specification is available at:
An HTML formatted version is also available at:
A new back-channel OpenID Connect Logout spec has been published at http://openid.net/specs/openid-connect-backchannel-1_0.html. This can coexist with or be used instead of the front-channel-based Session Management and HTTP-Based Logout specifications.
The abstract for the new specification states:
This specification defines a logout mechanism that uses back-channel communication between the OP and RPs being logged out; this differs from front-channel logout mechanisms, which communicate logout requests from the OP to RPs via the User Agent.
This completes publication of the three planned OpenID Connect logout mechanisms: two that communicate on the front-channel through the User Agent (browser) and this one that communicates on the back-channel, without involving the User Agent. See the Introduction for a discussion of the upsides and downsides of the different logout approaches. As much as we’d like there to be a single logout solution, both experience and extensive discussions led us to the conclusion that there isn’t a feasible one-size-fits-all approach.
Reviews of the new (and existing!) specifications are welcomed.
Thanks to John Bradley, Pedro Felix, Nat Sakimura, Brian Campbell, and Todd Lainhart for their contributions to the creation of the specification.
The JSON Web Key (JWK) Thumbprint specification is now RFC 7638 — an IETF standard. The abstract describes the specification as follows:
This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint.
Thanks to James Manger, John Bradley, and Nat Sakimura, all of whom participated in security discussions that led to the creation of this specification. Thanks also to the JOSE working group members, chairs, area directors, and other IETF members who contributed to the specification.
A JWK Thumbprint is used as the “sub” (subject) claim value in OpenID Connect self-issued ID Tokens.
Proof-of-Possession Key Semantics for JWTs draft -04 addresses the remaining working group comments received — both a few leftover WGLC comments and comments received during IETF 93 in Prague. The changes were:
jwk” for symmetric keys when the JWT is encrypted.jku” (JWK Set URL) member.cnf” (confirmation) claim is defined before it is used.cnf“, to represent additional proof-of-possession keys, using the same representation as “cnf“.The updated specification is available at:
An HTML formatted version is also available at:
Authentication Method Reference Values draft -02 changed the identifier for risk-based authentication from “risk” to “rba“, by popular acclaim, and added the identifier “sc” (smart card).
The specification is available at:
An HTML formatted version is also available at:
I’ve updated the Authentication Method Reference Values spec to incorporate feedback received from the OAuth working group. Changes were:
mca” (multiple-channel authentication), “risk” (risk-based authentication), and “user” (user presence test).The specification is available at:
An HTML formatted version is also available at:
The former JWS Signing Input Options specification has been renamed to JWS Unencoded Payload Option to reflect that there is now only one JWS Signing Input option defined in the spec — the “b64”:false option. The “sph” option was removed by popular demand. I also added a section on unencoded payload content restrictions and an example using the JWS JSON Serialization.
The specification is available at:
An HTML formatted version is also available at:
Powered by WordPress & Theme by Anders Norén