Musings on Digital Identity

Month: November 2012

Developer Preview of Microsoft JWT Support

Vittorio Bertocci just wrote about a developer preview release of JWT support for the Windows Identity Framework (WIF). Among other things, his catalog of places that JWT is already in production use is worth taking note of. I encourage those of you who are using JWTs to download it and give it a spin. Any feedback you could provide on how it works for your use cases would be very valuable.

OAuth 2.0 Multiple Response Type Encoding Practices

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

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

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:

Powered by WordPress & Theme by Anders Norén