Mike Jones: self-issued

Musings on Digital Identity

Category: Specifications Page 21 of 25

December 27, 2012 OpenID Connect Release

By

On December 28, 2012

In Claims, JSON, OAuth, OpenID, Specifications

OpenID logoNew versions of the OpenID Connect specifications have been released resolving numerous open issues raised by the working group. The most significant change is changing the name of the “user_id” claim to “sub” (subject) so that ID Tokens conform to the OAuth JWT Bearer Profile specification, and so they can be used as OAuth assertions. (Also, see the related coordinated change to the OAuth JWT specifications.) A related enhancement was extending our use of the “aud” (audience) claim to allow ID Tokens to have multiple audiences. Also, a related addition was defining the “azp” (authorized party) claim to allow implementers to experiment with this proposed functionality. (This is a slightly more general form of the “cid” claim that Google and Nat Sakimura had proposed.)

Other updates were:

  • The “offline_access” scope value was defined to request that a refresh token be returned when using the code flow that can be used to obtain an access token granting access to the user’s UserInfo endpoint even when the user is not present.
  • A new “tos_url” registration parameter was added so that the terms of service can be specified separately from the usage policy.
  • Clarified that “jwk_url” and “jwk_encryption_url” refer to documents containing JWK Sets – not single JWK keys.

Implementers need to apply these name changes to their code:

  • user_id -> sub
  • prn -> sub
  • user_id_types_supported -> subject_types_supported
  • user_id_type -> subject_type
  • acrs_supported -> acr_values_supported
  • alg -> kty (in JWKs)

See the Document History section of each specification for more details about the changes made.

This release is part of a coordinated release of JOSE, OAuth, and OpenID Connect specifications. You can read about the other releases here: JOSE Release Notes, OAuth Release Notes.

The new specification versions are:

December 27, 2012 OAuth JWT & Assssertions Release

By

On December 28, 2012

In Claims, JSON, OAuth, Specifications

OAuth logoNew versions of the OAuth JWT, JWT Bearer Profile, and Assertions specs have been released incorporating feedback since IETF 85 in Atlanta. The primary change is changing the name of the “prn” claim to “sub” (subject) both to more closely align with SAML name usage and to use a more intuitive name for this concept. (Also, see the related coordinated change to the OpenID Connect specifications.) The definition of the “aud” (audience) claim was also extended to allow JWTs to have multiple audiences (a feature also in SAML assertions).

An explanation was added to the JWT spec about why should be signed and then encrypted.

The audience definition in the Assertions specification was relaxed so that audience values can be OAuth “client_id” values. Informative references to the SAML Bearer Profile and JWT Bearer Profile specs were also added.

This release incorporates editorial improvements suggested by Jeff Hodges, Hannes Tschofenig, and Prateek Mishra in their reviews of the JWT specification. Many of these simplified the terminology usage. See the Document History section of each specification for more details about the changes made.

This release is part of a coordinated release of JOSE, OAuth, and OpenID Connect specifications. You can read about the other releases here: JOSE Release Notes, OpenID Connect Release Notes.

The new specification versions are:

HTML formatted versions are available at:

December 27, 2012 JOSE Release

By

On December 28, 2012

In Cryptography, JSON, Specifications

IETF logoNew versions of the JOSE specs have been released incorporating feedback since IETF 85 in Atlanta. The highlight of this release is the new JSON Private and Symmetric Key spec, which extends JWKs to be able to represent private and symmetric keys. These sensitive keys can then be protected for transmission and storage by JWE encryption of their JWK representations.

One new feature added to JWK is the ability to optionally specify which specific algorithm the key is intended to be used with. (This is already existing practice for keys in X.509 format.) For instance, a symmetric key might be annotated to say that it is to be used with the “HS256” algorithm. Because the natural field name for this functionality is “alg“, the “alg” name is now used for this purpose (matching JWS and JWE) and the key type (formerly “alg“) is now denoted by the “kty” field.

This release incorporates editorial improvements suggested by Jeff Hodges and Hannes Tschofenig in their reviews of the JWT specification. Many of these simplified the terminology usage. See the Document History section of each specification for more details about the changes made.

This release is part of a coordinated release of JOSE, OAuth, and OpenID Connect specifications. You can read about the other releases here: OAuth Release Notes, OpenID Connect Release Notes.

The new specification versions are:

HTML formatted versions are available at:

OAuth 2.0 Multiple Response Type Encoding Practices

By

On November 19, 2012

In OAuth, OpenID, Specifications

IETF logoOAuth 2.0 (a.k.a. RFC 6749) has an extension point for defining additional response_type values beyond the code and token values defined within the specification. The OAuth 2.0 Multiple Response Type Encoding Practices specification uses this extension point to define the additional response_type values id_token and none, as well as values for the combinations of code, token, and id_token. These response_type values are used by OpenID Connect, as well as other systems using OAuth 2.0.

I’m writing this now because I just updated the Multiple Response Types spec to add an IANA Considerations section to make IANA’s job easier when registering these additional response_type values. No normative changes were made.

The specification is available at:

JOSE and JWT specs updated for IETF 85 working group meetings

By

On November 8, 2012

In Claims, Cryptography, JSON, OAuth, Specifications

IETF logoI’ve made a small set of updates to the JSON Object Signing and Encryption (JOSE) and JSON Web Token (JWT) specs in preparation for the JOSE and OAuth working group meetings at IETF 85. These updates incorporate resolutions to issues that have been discussed by the working groups since publication of the previous drafts.

Normative changes to the working group specs were to add length fields for PartyUInfo and PartyVInfo values for key derivation calculations and to change the JWK field identifiers for RSA keys from (mod, xpo) to (n, e). Fields for representing the RSA private key values needed for Chinese Remainder Theorem (CRT) calculations were added to the JSON Private Key specification.

The updated specs are available at:

HTML formatted versions are available at:

See the history entries in the specs for detailed change descriptions.

Simple Web Discovery (SWD) Enabling Hosted Deployments

By

On November 4, 2012

In JSON, OpenID, Specifications

IETF logoI’ve updated the Simple Web Discovery (SWD) specification to incorporate a means of performing discovery on domains for which it may not be possible to create a .well-known endpoint. This can often be the case for hosted domains, where it is common for e-mail to be provided but no web server. This solution was developed in discussions by the OpenID Connect working group.

This draft is being published now to facilitate discussions of the need to enable discovery for hosted domains and possible solutions for doing so at the IETF Applications Area working group meeting at IETF 85 in Atlanta.

The updated specification is available at:

Changes made were:

  • Specified that the SWD server for a domain may be located at the simple-web-discovery subdomain of the domain and that SWD clients must first try the endpoint at the domain and then the endpoint at the subdomain.
  • Removed the SWD_service_redirect response, since redirection can be accomplished by pointing the simple-web-discovery subdomain to a different location than the domain’s host.
  • Removed mailto: from examples in favor of bare e-mail address syntax.
  • Specified that SWD servers may also be run on ports other than 443, provided they use TLS on those ports.

An HTML formatted version is available at:

Platform Support for JWA Crypto Algorithms

By

On October 28, 2012

In Cryptography, Events, JSON, Specifications

IETF logoIn preparation for discussions at the JOSE working group meeting at IETF 84 in Vancouver, BC, I did some investigation into the state of support for the JWA algorithms in common Web development platforms. This table contains the data gathered. It was also discussed at the July 2012 W3C WebCrypto F2F Meeting. I’m posting it now because I’d recently received a request for it and because it may be useful at the upcoming WebCrypto meeting at TPAC in Lyon and at IETF 85 in Atlanta.

Thanks to Roland Hedberg, Axel Nennker, Emmanuel Raviart, Nov Matake, Justin Richer, Edmund Jay, Wan-Teh Chang, Christopher Kula, and Ryan Sleevi for the data they provided. If you have more data that I should add, or believe that there are additional columns or rows we should track, please let me know.

JOSE and JWT specs incorporating working group decisions since IETF 84

By

On October 15, 2012

In Claims, Cryptography, JSON, Specifications

IETF logoNew versions of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) specifications have been released. These versions incorporate the decisions made by the JOSE working group during and since IETF 84.

The primary change was revising the JWE format to always use AEAD encryption algorithms. The companion change was defining two new composite AEAD algorithms “A128CBC+HS256” and “A256CBC+HS512” that use AES CBC to perform encryption and matching HMAC SHA-2 algorithms to perform an integrity check on the ciphertext and the parameters used to create it.

Other than that, all changes were local in scope, with no changes to JWS — other than changing the format of the “x5c” (X.509 Certificate Chain) from a string containing a list of certificate values to an array of strings containing certificate values. Likewise, the only changes to JWT were to track changes made in the specs that it uses.

Having addressed all the open issues with resolutions with apparent working group consensus, it’s my hope that the working group will decide to send these specifications to working group last call at IETF 85.

The companion JWS JSON Serialization and JWE JSON Serialization specs were also updated.

The working group specifications are available at:

The individual submission specifications are available at:

The document history entries (also in the specifications) are as follows:

http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-06

  • Changed x5c (X.509 Certificate Chain) representation from being a single string to being an array of strings, each containing a single base64 encoded DER certificate value, representing elements of the certificate chain.
  • Applied changes made by the RFC Editor to RFC 6749’s registry language to this specification.

http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06

  • Removed the int and kdf parameters and defined the new composite AEAD algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of AES CBC, which required the use of separate integrity and key derivation functions.
  • Included additional values in the Concat KDF calculation — the desired output size and the algorithm value, and optionally PartyUInfo and PartyVInfo values. Added the optional header parameters apu (agreement PartyUInfo), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encryption PartyVInfo). Updated the KDF examples accordingly.
  • Promoted Initialization Vector from being a header parameter to being a top-level JWE element. This saves approximately 16 bytes in the compact serialization, which is a significant savings for some use cases. Promoting the Initialization Vector out of the header also avoids repeating this shared value in the JSON serialization.
  • Changed x5c (X.509 Certificate Chain) representation from being a single string to being an array of strings, each containing a single base64 encoded DER certificate value, representing elements of the certificate chain.
  • Added an AES Key Wrap example.
  • Reordered the encryption steps so CMK creation is first, when required.
  • Correct statements in examples about which algorithms produce reproducible results.

http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06

  • Changed the name of the JWK RSA exponent parameter from exp to xpo so as to allow the potential use of the name exp for a future extension that might define an expiration parameter for keys. (The exp name is already used for this purpose in the JWT specification.)
  • Clarify that the alg (algorithm family) member is REQUIRED.
  • Correct an instance of “JWK” that should have been “JWK Set”.
  • Applied changes made by the RFC Editor to RFC 6749’s registry language to this specification.

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-06

  • Removed the int and kdf parameters and defined the new composite AEAD algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of AES CBC, which required the use of separate integrity and key derivation functions.
  • Included additional values in the Concat KDF calculation — the desired output size and the algorithm value, and optionally PartyUInfo and PartyVInfo values. Added the optional header parameters apu (agreement PartyUInfo), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encryption PartyVInfo).
  • Changed the name of the JWK RSA exponent parameter from exp to xpo so as to allow the potential use of the name exp for a future extension that might define an expiration parameter for keys. (The exp name is already used for this purpose in the JWT specification.)
  • Applied changes made by the RFC Editor to RFC 6749’s registry language to this specification.

http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-04

  • Promoted Initialization Vector from being a header parameter to being a top-level JWE element. This saves approximately 16 bytes in the compact serialization, which is a significant savings for some use cases. Promoting the Initialization Vector out of the header also avoids repeating this shared value in the JSON serialization.
  • Applied changes made by the RFC Editor to RFC 6749’s registry language to this specification.
  • Reference RFC 6755 — An IETF URN Sub-Namespace for OAuth.

http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-02

  • Changed to use an array of structures for per-recipient values, rather than a set of parallel arrays.

http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-02

  • Changed to use an array of structures for per-recipient values, rather than a set of parallel arrays.
  • Promoted Initialization Vector from being a header parameter to being a top-level JWE element. This saves approximately 16 bytes in the compact serialization, which is a significant savings for some use cases. Promoting the Initialization Vector out of the header also avoids repeating this shared value in the JSON serialization.

HTML formatted versions are available at:

OAuth 2.0 RFCs Completed

By

On October 12, 2012

In JSON, OAuth, Specifications

OAuth logoThe OAuth 2.0 Core and Bearer specifications are now RFC 6749 and RFC 6750. This completes the journey to standardize a pair of simple identity specifications that are already in very widespread use for Web, enterprise, cloud, and mobile applications. They make things better by enabling access to resources to be granted without giving the password for the resource to the party being granted access (a pattern that used to be all too common).

I believe that the completion of these RFCs will only accelerate the momentum behind the adoption of simple REST/JSON based identity solutions. Some of the related standards that are already well under way and in use include the OAuth Assertion Framework, the OAuth SAML 2.0 Assertion Profile and OAuth JWT Assertion Profile, JSON Web Token (JWT), the JSON Object Signing and Encryption (JOSE) specs — JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), and JSON Web Algorithms (JWA), and OpenID Connect. Watch this space for future developments. Like OAuth 2.0, all of these are the product of collaboration by numerous people around the world and in many industries to build and deploy simple, usable identity solutions that solve real-world problems.

The goal of all these specs is to standardize functionality that is not only useful, but is simple enough that it will actually be used. OAuth 2.0 is an early success story in this regard. While the number of words in the spec has increased since early drafts, most of that is due to doing a more complete job of describing things not to do (adding security considerations), rather than adding bells and whistles. It doesn’t get much simpler than a couple of HTTP GETs and replies with simple request parameters and responses.

Dick Hardt deserves special thanks for his role both in starting what became OAuth 2.0 and seeing it through to completion. I recommend his post on the process that brought us the OAuth 2.0 RFCs.

Updated OAuth Assertion Specifications

By

On September 18, 2012

In Claims, JSON, OAuth, Specifications

OAuth logoUpdated drafts of all three OAuth Assertion specifications have been published. These specs define how to use assertions/security tokens as OAuth 2.0 authorization grants and for client authentication. They are: Assertion Framework for OAuth 2.0, SAML 2.0 Bearer Assertion Profiles for OAuth 2.0, and JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0.

Language was added to all three explicitly clarifying that an assertion grant type can be used with or without client authentication via an assertion and that client authentication using an assertion is nothing more than an alternative way for a client to authenticate to the token endpoint. Two new examples were added to the SAML and JWT profile drafts to illustrate the use of assertions/security tokens in both cases. Thanks to Brian Campbell for making these updates.

The authors believe that draft-ietf-oauth-assertions and draft-ietf-oauth-saml2-bearer are now ready for Working Group Last Call.

The drafts are available at:

HTML-formatted versions are available at:

W3C WebCrypto API First Public Working Draft

By

On September 18, 2012

In Cryptography, Specifications

W3C logoAs many of you know, the W3C Web Cryptography Working Group is developing a WebIDL/JavaScript API for cryptography operations. They recently published their First Public Working Draft. One of their use cases is being able to use the WebCrypto API to implement the IETF JOSE specifications.

I encourage those of you who are interested to review the draft API specification. Comments can be sent to public-webcrypto-comments@w3.org. The latest public version of the specification can always be found at http://www.w3.org/TR/WebCryptoAPI/.

Also see the post by Virginie Galindo, the working group chair.

OAuth Assertion Framework draft -05

By

On September 10, 2012

In Claims, OAuth, Specifications

OAuth logoDraft 05 of the Assertion Framework for OAuth 2.0 has been published. It contains non-normative editorial changes to improve readability.

The draft is available at:

An HTML-formatted version is available at:

JSON Private Key Specification

By

On August 15, 2012

In Cryptography, JSON, Specifications

IETF logoW3C logoThe W3C WebCrypto working group recently made an inquiry to the IETF JOSE working group about the possibility of defining a JSON representation for private keys. To facilitate discussion of this topic by both working groups, I created a draft JSON Private Key specification. The specification is very simple; it just defines two additional members for the JWK structure for representing the private parts of Elliptic Curve and RSA keys.

The specification is available at:

A HTML-formatted version of the specification is available at:

OAuth Core -31 and OAuth Bearer -23 specs published

By

On August 1, 2012

In OAuth, Specifications

OAuth logoHopefully final versions of the OAuth Core and Bearer specs have been published. These versions correct an editorial issue with the security clarification made in Core -30 and remove David Recordon from the author lists, at his request.

The specifications are available at:

Changes in http://tools.ietf.org/html/draft-ietf-oauth-v2-31 are:

  • Clarify that any client can send client_id but that sending it is only required when using the code flow if the client is not otherwise authenticated.
  • Removed David Recordon’s name from the author list, at his request.

Changes in http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-23 are:

  • Removed David Recordon’s name from the author list, at his request.

HTML-formatted versions are available at:

IETF 84 versions of JOSE and JWT specifications

By

On July 31, 2012

In Claims, Cryptography, JSON, Specifications

IETF logoI’ve made a minor release of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) specifications to support the working group discussions at IETF 84 in Vancouver, BC. This release incorporates working group feedback since the minor release on July 16th and updates the lists of open issues in the JWE and JWA specifications.

The specifications are available at:

The document history entries (also in the specifications) are as follows:

http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-05

  • Added statement that “StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied”.
  • Indented artwork elements to better distinguish them from the body text.

http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-05

  • Support both direct encryption using a shared or agreed upon symmetric key, and the use of a shared or agreed upon symmetric key to key wrap the CMK.
  • Added statement that “StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied”.
  • Updated open issues.
  • Indented artwork elements to better distinguish them from the body text.

http://tools.ietf.org/html/draft-ietf-jose-json-web-key-05

  • Indented artwork elements to better distinguish them from the body text.

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-05

  • Support both direct encryption using a shared or agreed upon symmetric key, and the use of a shared or agreed upon symmetric key to key wrap the CMK. Specifically, added the alg values dir, ECDH-ES+A128KW, and ECDH-ES+A256KW to finish filling in this set of capabilities.
  • Updated open issues.

http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03

  • Added statement that “StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied”.
  • Indented artwork elements to better distinguish them from the body text.

HTML-formatted versions are available at:

Pre-IETF 84 versions of JOSE and JWT specifications

By

On July 16, 2012

In Claims, Cryptography, JSON, Specifications

IETF logoI’ve made a minor release of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) working group specifications and the JWS and JWE JSON Serialization (JWS-JS, JWE-JS) individual submission specifications in preparation for IETF 84 in Vancouver, BC. These versions incorporate feedback from working group members since the major release on July 6th, and update the lists of open issues in preparation for discussions in Vancouver (and on the working group mailing lists).

One significant addition is that the JWT and JWE-JS specs both now contain complete, testable examples with encrypted results. No normative changes were made.

The working group specifications are available at:

The individual submission specifications are available at:

The document history entries (also in the specifications) are as follows:

http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-04

  • Completed JSON Security Considerations section, including considerations about rejecting input with duplicate member names.
  • Completed security considerations on the use of a SHA-1 hash when computing x5t (x.509 certificate thumbprint) values.
  • Refer to the registries as the primary sources of defined values and then secondarily reference the sections defining the initial contents of the registries.
  • Normatively reference XML DSIG 2.0 [W3C.CR xmldsig core2 20120124] for its security considerations.
  • Added this language to Registration Templates: “This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted.”
  • Reference draft-jones-jose-jws-json-serialization instead of draft-jones-json-web-signature-json-serialization.
  • Described additional open issues.
  • Applied editorial suggestions.

http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04

  • Refer to the registries as the primary sources of defined values and then secondarily reference the sections defining the initial contents of the registries.
  • Normatively reference XML Encryption 1.1 [W3C.CR xmlenc core1 20120313] for its security considerations.
  • Reference draft-jones-jose-jwe-json-serialization instead of draft-jones-json-web-encryption-json-serialization.
  • Described additional open issues.
  • Applied editorial suggestions.

http://tools.ietf.org/html/draft-ietf-jose-json-web-key-04

  • Refer to the registries as the primary sources of defined values and then secondarily reference the sections defining the initial contents of the registries.
  • Normatively reference XML DSIG 2.0 [W3C.CR xmldsig core2 20120124] for its security considerations.
  • Added this language to Registration Templates: “This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted.”
  • Described additional open issues.
  • Applied editorial suggestions.

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-04

  • Added text requiring that any leading zero bytes be retained in base64url encoded key value representations for fixed-length values.
  • Added this language to Registration Templates: “This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted.”
  • Described additional open issues.
  • Applied editorial suggestions.

http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-02

  • Added an example of an encrypted JWT.
  • Added this language to Registration Templates: “This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted.”
  • Applied editorial suggestions.

http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-01

  • Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs).

http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-01

  • Added a complete JWE-JS example.
  • Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs).

HTML-formatted versions are available at:

OAuth Core draft -30 published

By

On July 15, 2012

In OAuth, Specifications

OAuth logoDraft -30 of the OAuth Core spec has been published. The only change was:

  • Added text explaining why the server_error and temporarily_unavailable error codes are needed.

The draft is available at:

An HTML-formatted version is available at:

Thanks to Dick Hardt for quickly resolving this issue.

OAuth Core -29 and OAuth Bearer -22 specs published

By

On July 12, 2012

In OAuth, Specifications

OAuth logoNew versions of the OAuth Core and Bearer specs have been published that are intended to address all outstanding issues. (Although see Dick Hardt’s forwarded note from Charles Honton, which may result in an additional issue.)

The specifications are available at:

Changes in http://tools.ietf.org/html/draft-ietf-oauth-v2-29 are:

  • Added “MUST” to “A public client that was not issued a client password MUST use the client_id request parameter to identify itself when sending requests to the token endpoint” and added text explaining why this must be so.
  • Added that the authorization server MUST “ensure the authorization code was issued to the authenticated confidential client or to the public client identified by the client_id in the request”.
  • Added Security Considerations section “Misuse of Access Token to Impersonate Resource Owner in Implicit Flow”.
  • Added references in the “Implicit” and “Implicit Grant” sections to particularly pertinent security considerations.
  • Added appendix “Use of application/x-www-form-urlencoded Media Type” and referenced it in places that this encoding is used.
  • Deleted “;charset=UTF-8” from examples formerly using “Content-Type: application/x-www-form-urlencoded;charset=UTF-8”.
  • Added the phrase “with a character encoding of UTF-8” when describing how to send requests using the HTTP request entity-body.
  • For symmetry when using HTTP Basic authentication, also apply the application/x-www-form-urlencoded encoding to the client password, just as was already done for the client identifier.
  • Added “The ABNF below is defined in terms of Unicode code points [W3C.REC xml 20081126]; these characters are typically encoded in UTF-8”.
  • Replaced UNICODENOCTRLCHAR in ABNF with UNICODECHARNOCRLF = %x09 / %x20-7E / %x80-D7FF / %xE000-FFFD / %x10000-10FFFF.
  • Corrected incorrect uses of “which”.
  • Reduced multiple blank lines around artwork elements to single blank lines.
  • Removed Eran Hammer’s name from the author list, at his request. Dick Hardt is now listed as the editor.

Changes in http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-22 are:

  • Removed uses of HTTPbis in favor of RFC 2616 and RFC 2617, since HTTPbis is not an approved standard.
  • Match formatting of artwork elements with OAuth core specification.

HTML-formatted versions are available at:

Thanks to Dick Hardt for editing the Core specification. Thanks to Julian Reschke for supplying the text in Core Appendix B on the use of the application/x-www-form-urlencoded encoding.

JSON Serialization Specifications Renamed

By

On July 9, 2012

In Cryptography, JSON, Specifications

IETF logoI renamed the JSON Serialization specifications so that they now have “jose” in the document name. Jim Schaad tells me that then they’ll automatically be added to the JOSE Related Documents list at http://datatracker.ietf.org/wg/jose/. No normative changes were made.

These documents use the JWS and JWE crypto calculations, but enable multiple parallel signatures and multiple recipients.

The new versions are:

HTML formatted versions are available at:

Updated Simple Web Discovery (SWD) Specification

By

On July 6, 2012

In JSON, Specifications

IETF logoI’ve updated the Simple Web Discovery (SWD) specification to incorporate editorial improvements suggested by Julian Reschke and to apply applicable editorial improvements also recently made to the JOSE specifications. No normative changes were made.

The updated specification is available at:

Changes made were:

  • Changed “requests use the x-www-form-urlencoded format” to “requests use query parameters” and changed “an x-www-form-urlencoded form” to “a form encoded using the application/x-www-form-urlencoded encoding algorithm”, both at the suggestion of Julian Reschke.
  • Updated examples to use “urn:example:” URNs rather than “urn:example.org:” URNs, also at Julian’s suggestion.
  • Applied applicable editorial improvements from JOSE specs to SWD.
  • Updated references to related specifications.

An HTML formatted version is available at:

Page 21 of 25

Previous

Next

Powered by WordPress & Theme by Anders Norén