[Openid-specs-ab] December 27, 2012 OpenID Connect Release

Mike Jones Michael.Jones at microsoft.com
Wed Jan 2 22:27:25 UTC 2013


Per http://hg.openid.net/connect/issue/601/standard-no-way-of-doing-idp-initiated, we decided that IdP initiated login was critical functionality.  SAML uses this in many many circumstances, and we decided that feature parity in this regard was critical.  Actually, at IIW, John and crew decided how to do this.  He's also checked it in, it turns out.  Look at bitbucket or expect a release with these changes in them shortly.  Please review.

Talk to you in the morning...

                                                                -- Mike

From: openid-connect-interop at googlegroups.com [mailto:openid-connect-interop at googlegroups.com] On Behalf Of Justin Richer
Sent: Wednesday, January 02, 2013 1:11 PM
To: openid-connect-interop at googlegroups.com
Cc: Mike Jones; openid-specs-ab at lists.openid.net
Subject: Re: December 27, 2012 OpenID Connect Release

OK, I'll admit that I had assumed these were the implementer's draft releases, and therefore more final than what I thought. I would argue that the same brokenness argument ought to apply here with the other specs. I'm planning to make the meeting tomorrow so we can hash some things out there.

Incidentally, I thought that we had all decided at IIW that IdP initiated login was a bad idea?

 -- Justin

On 01/02/2013 03:26 PM, Mike Jones wrote:
Fair questions, Justin.  First, this is not the Implementer's Draft release. A few more changes still need to be made to get there, including the ones you're mentioning about discovery and registration and also IdP initiated login.  This was an interim release to keep Connect on sync with JWT.  Because of the JWT changes, Connect would have been broken without this release.

The same isn't true of the discovery and registration changes. There, I think the working group's conservative approach, while still encouraging experimentation with the new specs, remains a good stance for the upcoming implementer's drafts.  We cam discuss that more on tomorrow's call if you like (7am Pacific).

Happy New Year!
-- Mike
________________________________
From: Justin Richer
Sent: 1/2/2013 9:31 AM
To: openid-connect-interop at googlegroups.com<mailto:openid-connect-interop at googlegroups.com>
Cc: Mike Jones; openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: December 27, 2012 OpenID Connect Release
It surprises me that the very fundamental user_id -> sub breaking change was introduced in this revision, but the group wanted to hold back on both registration and discovery until after this publication so as to limit the number of deep compatibility breaks. I guess what I don't understand is the willingness to break things in one area but hesitance in others, especially since the user_id -> sub change came up only very recently. Don't get me wrong, I'm very much in favor of *all* of these changes, but I don't understand the logic in how we're deciding what gets broken and when.

Also, as I recall the discussion, both of these documents were supposed to have a note at the top of them pointing them to the appropriate upstream draft (oauth2-dyn-reg and webfinger, respectively) as an impending change. I can only guess that these notes got lost during the holiday shuffle and the barrage of JOSE-related changes, but if there's any good way to get these pointers in place, I believe we should do so.

 -- Justin

On 12/28/2012 08:09 PM, Mike Jones wrote:
New 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<http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04>, and so they can be used as OAuth assertions.  (Also, see the related coordinated change to the OAuth JWT specifications<http://self-issued.info/?p=916>.)  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<http://self-issued.info/?p=913>, OAuth Release Notes<http://self-issued.info/?p=916>.

The new specification versions are:

*        http://openid.net/specs/openid-connect-basic-1_0-22.html

*        http://openid.net/specs/openid-connect-implicit-1_0-05.html

*        http://openid.net/specs/openid-connect-messages-1_0-14.html

*        http://openid.net/specs/openid-connect-standard-1_0-15.html

*        http://openid.net/specs/openid-connect-discovery-1_0-11.html

*        http://openid.net/specs/openid-connect-registration-1_0-13.html

*        http://openid.net/specs/openid-connect-session-1_0-10.html

                                                            -- Mike



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130102/75dabd97/attachment-0001.html>


More information about the Openid-specs-ab mailing list