[Openid-specs-ab] Spec call notes 7-Nov-11

[Mike Jones]

Spec call notes 7-Nov-11

Nat Sakimura
Edmund Jay
Mike Jones
George Fletcher

Agenda:
                Proposal to be able to get claims without an additional round trip (issue #281)
                Yaron Goland's comments
                Open Issues
                Editing
                Misc

Proposal to be able to get claims without an additional round trip (issue #281)
                John suggested to use implicit flow, have the response contain the values
                The code flow adds one round trip
                                First talk to authorization endpoint, get back the code
                                Then send code to token endpoint, get back results
                Whereas with the implicit flow
                                Only talk to authorization endpoint, get back the results

                Problem with implicit flow is that it makes the URL too big

                Must use code flow if claims are large (say 100K)
                We are using implicit flow in Basic
                                Everything must fit in URL fragments
                                Typical size limit of 2048 bytes

                Token endpoint different from userinfo, check_id endpoints (see OAuth section 3.2)

                Nat commented that one way of achieving this is write a different OAuth flow
                                Possibly called "userinfo"
                Or we could obtain it via the implicit flow (which has size limitations)
                Nat commented that in the assertion flow, you get back the data in the HTTP response
                                The resource owner password credential flow does this as well
                The JWT Assertion flow has the right properties
                                We would need to profile this for OpenID Connect purposes
                                                Requesting UserInfo claims
                                Nat also needed a binding for the assertion profile for his use cases

                Mike will look at the JWT Assertion spec and figure out whether there is a mechanism for requesting a response type
                Mike will ask Yaron how he was thinking of this working
                Mike will discuss whether we need to do this before going to Implementer's Drafts

                One concern is market fragmentation
                We could end up describing this request for functionality in the specs as something that may be added after these drafts

                We will continue to discuss this on the list and will talk about it some more on the Thursday call

Yaron Goland's comments:
                Mike will incorporate editorial improvements during his edits
                Mike will file issues for potential normative changes

Open Issues:
                282 - Allow other genders
                                Yes - Mike

                280 - Validation of TLS endpoints
                                Mike

                279 - Can you use the form encoding parameter method?
                                We will change the specs to allow the Authorization Header & POST with form-encoding, but not query string
                                Mike

Editing:
                John is done editing
                Edmund is done editing
                Mike is ready to start closing his issues

Misc:
                Nat will ask Pam for the updated spec diagram
                George knows of other comments; he will ask the person to join the WG
                We will have both calls next week - they will be at 7am in Taipei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111108/9f1249a1/attachment.html>