[Openid-specs-ab] Spec call notes 25-Jul-11

[Mike Jones]

Per the call yesterday, John and I investigated whether the implicit (token) grant type can be effectively used with native client applications.  The Native Applications section<http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-9> of the OAuth spec makes it clear that it can.  Given that most OAuth interactions today use the implicit grant type, we want to confirm the tentative decision made on the call yesterday to have the implicit grant type be the one required flow in the Lite spec.

                                                            -- Mike & John

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Mike Jones
Sent: Monday, July 25, 2011 4:06 PM
To: openid-specs-ab at lists.openid.net
Subject: [Openid-specs-ab] Spec call notes 25-Jul-11

Spec call notes 25-Jul-11

Nat Sakimura
Mike Jones
John Bradley
Edmund Jay
Breno de Medeiros

Agenda:
               Reviewing proposed edits by Breno and Casper Biering
               Edits for Lite spec
               Feedback from Torsten

Reviewing Breno's proposed edits
               Other than those we comment on here, we are using the resolutions in Nat's response note
               Should indicate the fact that the two flows can be used in combination
               when a client consists of different components that both maintain user
               signed-in state
                              Nat will take a stab at text for this
                              John asked whether this should be supported in Lite
                                             This should be in "Standard" - not in "Lite"
               Related question - do we want code flow in Lite as well as implicit or just implicit?
                              We should go with just implicit to keep Lite as simple as possible

               Breno's comments about cross-domain post message and HTML5 (starting "- Client sends a request to authorization server -> Client submits"...)
                              Somebody (probably Breno) needs to propose normative text for this
                              Since it affects interop
                              In further discussions, we agreed that we want to mostly refer to OAuth 2 and not do Connect-specific things when possible
                                             So post message flow should happen in OAuth 2 - not OpenID Connect

               Per Breno's comments about code+token
                              We agreed that this doesn't belong in Lite
                              (Per OAuth draft 19 & 20, this also becomes "code token")


               JWT format will used for id_token, but id_token is not part of Lite

Reviewing Caspar's proposed edits
               Nat agrees with all of Caspar's proposed edits - Mike to review and check in
               We agreed that redirect_uri should be required for now (as it already is)

Breno requested that remove the native application text in the session management spec
               We're not sure that this is right yet
               Code flow needed for Native apps
                              We need to investigate this if we're only mandating token flow in Lite
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110726/ebddb0bf/attachment.html>