Mike Jones: self-issued

Musings on Digital Identity

Author: Mike Jones Page 24 of 33

Building the Internet's missing identity layer

OpenID Connect has won the 2012 European Identity Award

By

On April 18, 2012

In Claims, Events, JSON, OAuth, Specifications

OpenID logoI’m thrilled to report that OpenID Connect has won the 2012 European Identity Award for Best Innovation/New Standard. I appreciate the recognition of what we’ve achieved to date with OpenID Connect and its potential to significantly change digital identity for the better. As Dave Kearns wrote in the OpenID Foundation announcement about the award:

I’m pleased that Kuppinger Cole has granted OpenID Connect the award for Best Innovation/New Standard this year. What’s most impressive is that this elegantly simple design resulted from the cooperation of such a diverse global set of contributors. I expect OpenID Connect to have a substantial positive impact on usable, secure identity solutions both for traditional computing platforms and mobile devices. My congratulations to the OpenID Foundation!

My thanks to all who have contributed to the OpenID Connect specifications to date and especially to the developers who have implemented draft versions, providing essential feedback needed to refine the specs on the road to final standards. I look forward to seeing what people will accomplish with OpenID Connect!

April 10, 2012 OpenID Connect Update Release

By

On April 13, 2012

In Claims, JSON, OAuth, OpenID, Specifications

OpenID logoThe OpenID Connect working group has released an update to the OpenID Connect specifications that continues incorporating significant developer feedback received, while maintaining as much compatibility with the implementer’s drafts as possible. The Connect specs have also been updated to track updates to the OAuth and JOSE specs, which they use. The primary normative changes are as follows:

  • Make changes to allow path in the issuer_identifier, per issue #513
  • Add hash and hash check of access_token and code to id_token, per issue #510
  • Split encrypted response configurations into separate parameters for alg, enc, int
  • Added optional id_token to authorization request parameters, per issue #535
  • Now requested claims add to those requested with scope values, rather than replacing them, per issue #547
  • Added error interaction_required and removed user_mismatched, per issue #523
  • Changed invalid_request_redirect_uri to invalid_redirect_uri, per issue #553
  • Removed “embedded” display type, since its semantics were not well defined, per issue #514

A significant non-normative addition is:

  • Add example JS code for Basic client

Implementers are particularly encouraged to build and provide feedback on the new and modified features.

The new versions are available from http://openid.net/connect/ or at:

JSON Web Token (JWT) Specification Draft -08

By

On March 12, 2012

In Claims, JSON, Specifications

IETF logoDraft 08 of the JSON Web Token (JWT) specification has been published. It uses the -01 versions of the JOSE specifications and also contains these changes:

  • Removed language that required that a JWT must have three parts. Now the number of parts is explicitly dependent upon the representation of the underlying JWS or JWE.
  • Moved the “alg”:”none” definition to the JWS spec.
  • Registered the application/jwt MIME Media Type.
  • Clarified that the order of the creation and validation steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps.
  • Corrected the Magic Signatures and Simple Web Token (SWT) references.

This specification is available at:

An HTML formatted version is available at:

Draft -01 of JSON Crypto Specs: JWS, JWE, JWK, JWA, JWS-JS, JWE-JS

By

On March 12, 2012

In Cryptography, JSON, Specifications

IETF logoNew versions of the IETF JSON Object Signing and Encryption (JOSE) specifications are now available that incorporate working group feedback since publication of the initial versions. They are:

  • JSON Web Signature (JWS) — Digital signature/HMAC specification
  • JSON Web Encryption (JWE) — Encryption specification
  • JSON Web Key (JWK) — Public key specification
  • JSON Web Algorithms (JWA) — Algorithms and identifiers specification

The most important changes are:

  • Added a separate integrity check for encryption algorithms without an integral integrity check.
  • Defined header parameters for including JWK public keys and X.509 certificate chains directly in the header.

See the Document History section in each specification for a more detailed list of changes.

Corresponding versions of the JSON Serialization specs, which use these JOSE drafts, are also available. Besides using JSON Serializations of the cryptographic results (rather than Compact Serializations using a series of base64url encoded values), these specifications also enable multiple digital signatures and/or HMACs to applied to the same message and enable the same plaintext to be encrypted to multiple recipients. They are:

  • JSON Web Signature JSON Serialization (JWS-JS)
  • JSON Web Encryption JSON Serialization (JWE-JS)

These specifications are available at:

HTML formatted versions are available at:

OAuth 2.0 Bearer Token Specification Draft -18

By

On March 12, 2012

In OAuth, Specifications

OAuth logoDraft 18 of the OAuth 2.0 Bearer Token Specification has been published. It contains the following changes:

  • Changed example bearer token value from vF9dft4qmT to mF_9.B5f-4.1JqM.
  • Added example access token response returning a Bearer token.

The draft is available at:

An HTML-formatted version is available at:

JSON Serializations for JWS and JWE

By

On March 5, 2012

In Cryptography, JSON, Specifications

IETF logoParticipants in the JOSE working group have described use cases where a JSON top-level representation of digitally signed, HMAC’ed, or encrypted content is desirable. They have also described use cases where multiple digital signatures and/or HMACs need to applied to the same message and where the same plaintext needs to be encrypted to multiple recipients.

Responding to those use cases and working group input, I have created two new brief specifications:

  • JSON Web Signature JSON Serialization (JWS-JS)
  • JSON Web Encryption JSON Serialization (JWE-JS)

These use the same cryptographic operations as JWS and JWE, but serialize the results into a JSON objects, rather than a set of base64url encoded values separated by periods (as is done for JWS and JWE to produce compact, URL-safe representations).

These drafts are available at:

HTML-formatted versions are available at:

Feedback welcome!

OAuth 2.0 Bearer Token Specification Draft -17

By

On February 17, 2012

In OAuth, Specifications

OAuth logoDraft 17 of the OAuth 2.0 Bearer Token Specification has been published. This version changes the RFCs referenced for certificate chain verification. The wording was proposed by Alexey Melnikov as part of the Gen-ART review.

It contains the following changes:

  • Restore RFC 2818 reference for server identity verification and add RFC 5280 reference for certificate revocation lists, per Gen-ART review comments.

The draft is available at:

An HTML-formatted version is available at:

OpenID Connect Interop in Progress

By

On February 17, 2012

In Claims, Events, Interoperability, JSON, OAuth, OpenID, Specifications

OSIS logoOpenID logoThe Third OpenID Connect Interop is currently under way — this time based upon approved Implementer’s Drafts. Currently 7 implementations are being tested, with I believe more to be added. The interop is designed to enable people to test the implementations they’ve built against other implementations and verify that specific features that they’ve built are working correctly. This has several benefits: it helps debug implementations, it helps debug the specifications, and it results in greater interoperability among OpenID Connect implementations.

As background, like the other OSIS interops, the OpenID Connect interop is an opportunity for implementers to try their code against one another’s in a systematic way. It is not a conformance test; participants do not “pass” or “fail”. There is no requirement that you must support particular features to participate or that you must participate in all aspects of the interop.

If you’d like to participate in the interop, join the OpenID Connect Interop mailing list and send us a note there saying who your interop contact person will be, the name of your organization (can be an individual), the name of your implementation (can be your name), and a list of the online testing endpoints for your implementation. Testing is performed online on your schedule, with results recorded on the interop wiki. That being said, an in-person meeting of interop participants will also be held on Friday, March 2 in San Francisco (the week of RSA) for those who are able to attend.

OpenID Connect Implementer’s Drafts Approved

By

On February 17, 2012

In Claims, JSON, OAuth, OpenID, Specifications

OpenID logoThe OpenID Foundation members have overwhelmingly voted to approve the OpenID Connect specifications as Implementer’s Drafts. This is an important milestone in the process of completing the OpenID Connect specifications.

Implementer’s Drafts are stable versions of specifications intended for trial implementations and deployments that provide specific IPR protections to those using them. Implementers and deployers are encouraged to continue to provide timely feedback to the working group on the specifications based upon their experiences with them.

Greg Keegstra and Axel Nennker Elected to OpenID Board

By

On February 14, 2012

In OpenID, People

OpenID logoMy congratulations to Greg Keegstra and Axel Nennker for their election to the OpenID Board of Directors. Greg brings strong marketing chops and his can-do spirit to the board. Axel returns with his mix of deep technical expertise and common sense. I’m looking forward to serving with both of you!

Vote to Approve OpenID Connect Implementer’s Drafts Under Way

By

On February 8, 2012

In Claims, JSON, OAuth, OpenID, Specifications

OpenID logoThe vote to approve six OpenID Connect specification drafts as OpenID Foundation Implementer’s Drafts is under way. To vote, go to https://openid.net/foundation/members/polls/62 and log in using your OpenID by the morning of Wednesday, February 15th. For more information about OpenID Connect, visit http://openid.net/connect/.

OAuth 2.0 Bearer Token Specification Draft -16

By

On January 30, 2012

In OAuth, Specifications

OAuth logoDraft 16 of the OAuth 2.0 Bearer Token Specification has been published. This version contains a proposed resolution to the auth-param syntax issue that has been reviewed by Julian Reschke, Mark Nottingham, and the OAuth WG chairs. It also addresses the Gen-ART review comments by Alexey Melnikov.

It contains the following changes:

  • Use the HTTPbis auth-param syntax for Bearer challenge attributes.
  • Dropped the sentence “The realm value is intended for programmatic use and is not meant to be displayed to end users”.
  • Reordered form-encoded body parameter description bullets for better readability.
  • Added [USASCII] reference.

The draft is available at:

An HTML-formatted version is available at:

OpenID Connect in a Nutshell

By

On January 24, 2012

In Documentation, OpenID, People

OpenID logoNat Sakimura has written a valuable post describing OpenID Connect in a nutshell. It shows by example how simple it is for relying parties to use basic OpenID Connect functionality. If you’re involved in OpenID Connect in any way, or are considering becoming involved, his post is well worth reading.

Initial IETF JOSE Specs: JWS, JWE, JWK, JWA

By

On January 18, 2012

In Cryptography, JSON, Specifications

IETF logoThe initial versions of the IETF JSON Object Signing and Encryption (JOSE) specifications are now available. They are:

  • JSON Web Signature (JWS) — Digital signature/HMAC specification
  • JSON Web Encryption (JWE) — Encryption specification
  • JSON Web Key (JWK) — Public key specification
  • JSON Web Algorithms (JWA) — Algorithms and identifiers specification

They are refactored from the previous individual submission versions to move algorithms and identifiers into the separate JSA specification, per the working group charter. Also, per the working group’s input, the terminology usage has been changed to no longer call both digital signatures and HMACs “signatures”. The JOSE versions contain no normative changes from the individual submission versions.

These specifications are available at:

HTML formatted versions are available at:

OpenID Connect Implementer’s Draft Review

By

On December 23, 2011

In Claims, Federation, JSON, OAuth, OpenID, Specifications

OpenID logoOpenID Connect is a simple identity layer built on top of OAuth 2.0. It enables clients to verify the identity of and to obtain basic profile information about an end-user. It uses RESTful protocols and JSON data structures to provide a low barrier to entry. The design philosophy behind OpenID Connect is “make simple things simple and make complex things possible”.

OpenID Connect is designed to cover a range of scenarios and use cases including Internet, enterprise, cloud, and mobile, to span security & privacy requirements from non-sensitive information to highly secure, and to span sophistication of claims usage, from basic default claims to specific requested claims to aggregated and distributed claims. It maximizes the simplicity of implementations by reusing existing OAuth 2.0, JWT, and SWD specs and employing a modular structure, allowing deployments to utilize only the pieces they need.

OpenID Connect has a number of key differences from OpenID 2.0. Among them are: support for native client applications, identifiers using e-mail address format, standard UserInfo endpoint for retrieving basic claims about the end-user, being designed to work well on mobile phones, use of JSON/REST rather than XML, support for encryption and higher LoAs, and support for distributed and aggregated claims.

Today marks a milestone in the OpenID Connect specification development: the OpenID Foundation announced that the current set of drafts is being reviewed for approval as Implementer’s Drafts. An Implementer’s Draft is a stable version of a specification intended for implementation and deployment that provides intellectual property protections to implementers of the specification. These drafts are the product of incorporating months of feedback from implementers and reviewers of earlier specification drafts, including feedback resulting from interop testing. Thanks to all of you who contributed to the development of OpenID Connect!

OAuth 2.0 Bearer Token Specification Draft -15

By

On December 18, 2011

In OAuth, Specifications

OAuth logoDraft 15 of the OAuth 2.0 Bearer Token Specification has been published. It contains the following changes:

  • Clarified that form-encoded content must consist entirely of ASCII characters.
  • Added TLS version requirements.
  • Applied editorial improvements suggested by Mark Nottingham during the APPS area review.

The draft is available at:

An HTML-formatted version is available at:

SWD, JWT, JWS, JWE, JWK, and OAuth JWT Profile specs updated

By

On December 14, 2011

In Claims, Cryptography, JSON, OAuth, Specifications

OAuth logoNew versions of the SWD, JWT, JWS, JWE, JWK, and OAuth JWT Profile specs have been posted. They address a number of comments received on the JOSE list and at the JOSE WG meeting in Taipei and make a number of clarifications, corrections, and editorial improvements.

The only breaking change made was to use short names in the JWK spec, as suggested during the WG meeting in Taipei, since JWK Key Object values are used as JWE Ephemeral Public Keys, and so compactness matters. This also required corresponding changes in the JWE spec.

This checkin moves the definitions of the “prn” (principal) and “jti” (JSON Token ID) claims from other specs into the JWT spec, as both of these claims enable general token functionality that is likely to be used in many contexts.

This checkin is intended to be the last set of individual submissions of the JWS, JWE, and JWK drafts before they are refactored and submitted to the JOSE WG as working group drafts. The primary changes requested by the JOSE WG but not yet done are to break the algorithm profiles and identifiers out into a new spec and to rework the terminology in the signature spec to use different terms for digital signature and HMAC integrity operations.

See the Document History sections of each document for a detailed description of the changes made. These documents are available at:

HTML-formatted versions are available at:

Special thanks to Jim Schaad for his detailed comments on the JWS and JWE specs, many of which were incorporated into these drafts.

OAuth 2.0 JWT Bearer Token Profiles Specification Draft -02

By

On November 15, 2011

In Claims, JSON, OAuth, Specifications

OAuth logoDraft 02 of the OAuth 2.0 JWT Bearer Token Profiles Specification has been published. It contains the following changes:

  • Removed remaining vestiges of normative text talking about SAML that remained from the SAML Profile draft.
  • Replaced all references where the reference is used as if it were part of the sentence (such as “defined by [I-D.whatever]”) with ones where the specification name is used, followed by the reference (such as “defined by Whatever [I-D.whatever]”).

The draft is available at these locations:

OAuth 2.0 Bearer Token Specification Draft -14

By

On November 11, 2011

In OAuth, Specifications

OAuth logoDraft 14 of the OAuth 2.0 Bearer Token Specification has been published. It contains the following changes:

  • Changes made in response to review comments by Security Area Director Stephen Farrell. Specifically:
  • Strengthened warnings about passing an access token as a query parameter and more precisely described the limitations placed upon the use of this method.
  • Clarified that the realm attribute MAY included to indicate the scope of protection in the manner described in HTTP/1.1, Part 7 [I D.ietf httpbis p7 auth].
  • Normatively stated that “the token integrity protection MUST be sufficient to prevent the token from being modified”.
  • Added statement that “TLS is mandatory to implement and use with this specification” to the introduction.
  • Stated that TLS MUST be used with “a ciphersuite that provides confidentiality and integrity protection”.
  • Added “As a further defense against token disclosure, the client MUST validate the TLS certificate chain when making requests to protected resources” to the Threat Mitigation section.
  • Clarified that putting a validity time field inside the protected part of the token is one means, but not the only means, of limiting the lifetime of the token.
  • Dropped the confusing phrase “for instance, through the use of TLS” from the sentence about confidentiality protection of the exchanges.
  • Reference RFC 6125 for identity verification, rather than RFC 2818.
  • Stated that the token MUST be protected between front end and back end servers when the TLS connection terminates at a front end server that is distinct from the actual server that provides the resource.
  • Stated that bearer tokens MUST not be stored in cookies that can be sent in the clear in the Threat Mitigation section.
  • Replaced sole remaining reference to [RFC2616].
  • Replaced all references where the reference is used as if it were part of the sentence (such as “defined by [I-D.whatever]”) with ones where the specification name is used, followed by the reference (such as “defined by Whatever [I-D.whatever]”).
  • Other on-normative editorial improvements.

The draft is available at these locations:

Updated OAuth JWT Bearer Token Profile and OAuth Assertion Profile specs

By

On October 31, 2011

In Claims, JSON, OAuth, Specifications

OAuth logoI updated the OAuth JWT Bearer Token Profile spec to track the changes made in the OAuth SAML Bearer Token Profile spec. Changes were:

draft-jones-oauth-jwt-bearer-01:

  • Merged in changes from draft-ietf-oauth-saml2-bearer-09. In particular, this draft now uses draft-ietf-oauth-assertions, rather than being standalone. It also now defines how to use JWT bearer tokens both for Authorization Grants and for Client Authentication.

Meanwhile, Chuck Mortimore updated the OAuth Assertion Profile spec to incorporate working group feedback. In particular, the client_id parameter is now optional, as in some cases it may be carried in the assertion, rather than as a parameter.

The specs are available in the standard places. The HTML versions can be found at these locations:

Feedback welcome!

Page 24 of 33

Previous

Next

Powered by WordPress & Theme by Anders Norén