[Openid-specs-ab] Notes from OpenID Connect Meeting 6-May-13

[Mike Jones]

Notes from OpenID Connect Meeting 6-May-13

Attendees:
               Mike Jones
               Amanda Anganes
               Don Thibeau
               Bryant Cutler
               Ian Wesley-Smith
               Tony Nadalin
               George Fletcher
               Axel Nennker
               Tom Brown
               John Bradley
               Justin P. Richer
               Henrik Biering
               Johnny Bufu
               Darius Dunlap
               Pamela Dingle
               Karen O'Donoghue
               Oliver Zhang
               Nov Matake
               Paul Lee
               Kevin Marks
               Naveen Agarwal
               Breno de Medeiros
               Marla Hay
               Leif Johansson
               Valter Nordh

Agenda:
               Implementer's Draft Status
               Open Issues
               Spec Details:
                              Nonce Entropy Recommendations
                              Returning ID Token from Token Endpoint when using "code id_token"
                              Expected behavior of time fields when using Refresh Tokens
                              Review audience/azp semantics
                              Version String
                              SSO claims without UserInfo claims
               Upcoming Interops
               Native Client Application Status

Implementer's Draft Status
               JOSE edits resulting from last week's interim WG meeting are happening this week
               Edits resulting from this working group meeting will happen right after that
               We agreed that we'll be ready for the implementer's draft vote after that
                              Ideally, one-two weeks out

Open Issues
               We decided how to address the two new open issues
               Both will result in clarifications in Basic for optional fields

Nonce Entropy Recommendations
               We will say that sufficient entropy must be present in the nonce values used to prevent attackers from guessing values
                              So, for instance, fixed strings and incrementing values are unacceptable
               We will clarify that OPs should perform no processing on nonce values, other than echoing them back in issued ID Tokens
               Guessing nonce values could enable attackers to silently log you into RPs without you being aware of it

Returning ID Token from Token Endpoint when using "code id_token"
               This is done to enable hybrid clients where the browser uses the value returned in the front channel and the Web site uses the value returned in the back channel
               The validation information in both ID Tokens must be identical

Expected behavior of time fields when using Refresh Tokens
               We determined that the language in Messages 2.2.3 (Access Token Response) needs a few enhancements
               We need to include "aud" in the list of elements that must be the same
               We will further clarify that "azp" must be the same
               We will format the requirements as a bulleted list, for better readability

Review audience/azp semantics
               We will clarify that when an ID Token is used as a hint, that the party receiving the hint need not be an audience of the token
               Relying parties expressed a need to be able to know who the ID Token is issued to
                              We decided that we will use the "azp" field for this
                              "azp" will be single-valued
                              While ideally this would be named something closer to "issued to", we will leave the name "azp" so as not to break existing deployments
                              Breno pointed out that originally we had an issued_to field but that it was removed.  This brings us full circle.

Version String
               We had a surprisingly long discussion of protocol versioning considerations
               We agreed that the "version":"3.0" value in Discovery is insufficient
               In particular, breaking changes would likely need a different path than /.well-known/openid-configuration
               Breno took the position that it was up to people extending the protocol to decide how to best extend it
                              And that we shouldn't do a half-way job on it now
               Some felt that including "version":"3.0" would unnecessarily break clients if the value was changed when backwards-compatible extensions are used
                              They advocated deleting the discovery version from the spec
               So as to make a decision about what to include in the forthcoming Implementer's Drafts, a vote was held on whether to keep it for now
                              2 voted to keep it; 5 voted to drop it; 7 voted "don't care"
               People are encouraged to continue discussing this on the mailing list

SSO claims without UserInfo claims
               It was observed that some OPs in closed system environments may use OpenID Connect SSO but may not implement a UserInfo endpoint
               We discussed whether we should allow those systems to say that they are implementing OpenID Connect or not
                              These systems will exist whatever we decide
                              We decided that it was better to have those systems be in the OpenID Connect tent, rather than outside of it
               The "userinfo_endpoint" discovery field was already only RECOMMENDED
               We will update the Messages Implementation Considerations to make the UserInfo endpoint optional for closed-system OPs

Upcoming Interops
               Once we have Implementer's Draft specs, we will start a new round of interop testing
               Pam and Mike will create the OC5 interop at http://osis.idcommons.net/ next week while in Munich

Native Client Application Status
               Pam did a demo of her native client iOS application
               She reported that way more than 80% of the work was XCode related and not OpenID Connect related
               She said that the OpenID Connect parts were very easy
               People can e-mail Pam now for a TestFlight invitation to be able to install and run the app themselves

Photos of the four whiteboards used to record the agenda and take notes are also attached
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Notes from OpenID Connect Meeting 6-May-13 - Board 1.jpg
Type: image/jpeg
Size: 717034 bytes
Desc: Notes from OpenID Connect Meeting 6-May-13 - Board 1.jpg
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Notes from OpenID Connect Meeting 6-May-13 - Board 2.jpg
Type: image/jpeg
Size: 540626 bytes
Desc: Notes from OpenID Connect Meeting 6-May-13 - Board 2.jpg
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Notes from OpenID Connect Meeting 6-May-13 - Board 3.jpg
Type: image/jpeg
Size: 527573 bytes
Desc: Notes from OpenID Connect Meeting 6-May-13 - Board 3.jpg
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Notes from OpenID Connect Meeting 6-May-13 - Board 4.jpg
Type: image/jpeg
Size: 364904 bytes
Desc: Notes from OpenID Connect Meeting 6-May-13 - Board 4.jpg
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0003.jpg>