James, OAuth is typically used _once_ to get a long-term capability to access user's data. The hybrid protocol is used *many time* to login the user.
So the step _after_ the authorization will happen infrequently, and it is not a penalty issue to require. The step _before_ the authorization (if mandated in the hybrid) must happen _every_time_ because the RP/consumer does not know who the user is. It is throwaway busywork in the vast majority of cases. On Wed, Nov 19, 2008 at 5:19 AM, Manger, James H <[EMAIL PROTECTED]> wrote: > How much special knowledge about the OP/SP is an app expected to have to use > the OpenID/OAuth hybrid protocol? [and some performance issues at the end] > > A common case might be an app built to enhance one specific service. It is > probably realistic to assume such an app is registered with the SP, and has > hardwired knowledge about its OAuth URIs, scopes, signing modes etc. > > Another case is an app that dynamically learns who a user's OP is (eg from > OpenID discovery) and which SP the user uses for the service of interest > (perhaps from the same OpenID discovery). The app notices that the OP and SP > are the same (how?) and that they support the hybrid protocol (how?). This > app understands OpenID, OAuth, hybrid, and the type of service of interest -- > but has no special knowledge about this user's specific OP/SP. > > The first case may cover many immediate pain points, particularly as OpenID > and OAuth are in their infancy. However, a standard would be much more useful > for the whole community and in the medium term if it supported the second > case as well. > > Even if the discovery aspects are not solved immediately, the hybrid protocol > should not *preclude* apps without SP-specific knowledge once discovery > mechanisms emerge. > > > The current hybrid draft adds openid.oauth.consumer and openid.oauth.scope > fields to an OpenID request. The former forces the app to be pre-registered. > The latter requires the app to know about the SP's specific scopes. > > It seems possible that more parameters might be required in future: perhaps > permissions (eg read/write), or lifetime (once-off, for 24 hours, forever). > > All these parameters seem to tightly couple the app to the SP. > > An alternative is to add one opaque handle to the OpenID request: a request > token. To add a new scope, offer a new permission, support a new lifetime, > etc an SP can offer a new URI for getting the new request tokens. As far as > the app code is concerned it is just a URI, like any other URI. It doesn't > necessarily need code that understands permissions, or scopes, or lifetimes > etc. > > > > Breno de Medeiros said the initial OAuth request for a token "adds a > (probably unacceptable) redundant server-to-server call for *every* > authentication request". > > It may be better for performance to omit the request AFTER the redirect, > instead of the request BEFORE the redirect. > > OAuth involves: > 1. get request token > 2. redirect user to do authorization > 3. swap request token for access token > 4. do stuff > > Step 3 was added to OAuth to support apps that could not launch/redirect-to a > browser. Such apps need the user to manually type in a token, which needs to > be short to be human-friendly. Step 3 allows a short token to be exchanged > for a longer one that can encode lots of state so the service can operate in > a stateless (scalable) manner. > Step 3 was kept for all OAuth apps (not just those that could not > launch/redirect a browser) to keep the spec simple. > > The hybrid protocol could save a request/response pair by dropping step 3 (or > make it optional so apps that cannot launch/redirect-to a browser can use it). > > > The initial request for a request token (step 1) does not have to affect the > user experience -- as it can be done in advance. An app could get request > tokens in the background and cache them until one is needed for a hybrid > auth/authz redirect. > > > Keeping step 1 but omitting step 3 means the access token needs to be > returned in the authentication/authorization response. The request token > secret can be used instead of getting a new access token secret. > > The hybrid spec says [in section 3 Purpose] > "For security reasons, the OAuth access token is not returned in the URL." > It is not clear what these security reasons are. I suspect they only apply > because the hybrid protocol had dropped the token secret from step 1. > > > [It might not even be necessary to perform step 1 for *every* authentication > request. If the returned token simply encodes the scope and/or consumer > identity, then the service could set a Cache-Control header indicating that > the token can be reused for, say, any authentication requests in the next day > (I will have to think about any security implications). > Alternatively define a way for an app to get a batch of request tokens in one > go.] > > > > James Manger > [EMAIL PROTECTED] > Identity and security team — Chief Technology Office — Telstra > _______________________________________________ > specs mailing list > [email protected] > http://openid.net/mailman/listinfo/specs > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) _______________________________________________ specs mailing list [email protected] http://openid.net/mailman/listinfo/specs
