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.
Archive for November, 2012
OAuth 2.0 (a.k.a. RFC 6749) has an extension point for defining additional
response_type values beyond the
token values defined within the specification. The OAuth 2.0 Multiple Response Type Encoding Practices specification uses this extension point to define the additional
none, as well as values for the combinations of
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:
I’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.
I’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-discoverysubdomain 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_redirectresponse, since redirection can be accomplished by pointing the
simple-web-discoverysubdomain to a different location than the domain’s host.
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: