OpenID/Oauth hybrid

[Breno de Medeiros]

On Wed, Nov 19, 2008 at 4:03 PM, Manger, James H
<James.H.Manger at team.telstra.com> wrote:
> Breno,
>
> Thanks for your responses.
>
>> The scopes are needed for the approval page to be rendered.
>> The whole thing is meaningless otherwise
>
> I absolutely agree that the auth/authz redirect needs to know what actions are being authorized, ie the "scope". I don't want to eliminate the scope, just use a single opaque token to represent it -- regardless of which aspects any specific SP needs the scope to encompass [app id, resources, permissions, lifetimes...]. The token comes from a URI, which is what really represents the scope.
>
>> You mean that the app has to understand all of the above,
>> but will use that knowledge during the discovery process,
>> rather than authorization
>
> *Something* has to understand all of the above [scope, permissions, lifetime...] -- but it does not have to be the app.

Sure. That something is able to inform the app what to put in the
scope parameter?

> It can be the app. It can be the user. It can be another system that provides discovery details. Perhaps it can be a hyperlink on a web page.
>
> The app just has a URI and it flows from there.

The scope is an optional element of this spec. If and when we have a
discovery mechanism that makes this obsolete, than it can be safely
left empty. Or discovery could provide what to use as the scope
parameter. At this point, since we do not have discovery, the spec
needs an explicit place to talk about scope.

>
>
>> If that [discovery] effort is successful,
>> I do not think any of these issues are intractable.
>
> It is conceivable that discovery can provide 'scope' strings, and even 'consumer' values for unregistered apps -- but that does not feel like it fits well with the web architecture. It feels unnecessarily complicated and OAuth-specific.
> I can image discovery providing:
>  A URI for my address book;
>  A URI for my calendar;
>  A URI for my photos;
>  A separate URI for my photos of a particular conference;
> I am concerned that with the current hybrid draft, discovery will have to define 'scope' strings etc in addition to a URI to access a service. I doubt generic web discovery mechanisms will
> offer that.

Scope strings? what about just using the above URIs as scopes? Clearly
you need to find already the OpenID+OAuth hybrid endpoint & the URIs
indicating scope. Each of these URIs could also have metadata
associated with them via XRD, e.g., they could define their own scope
strings. Or in the absence of these, the URIs themselves could be used
as scopes. There are many options here. I am not sure all of them
violate the web infrastructure or are OAuth-specific.

Let me pose this problem then: Drop the request token request in the
OAuth spec. Now you have discovery and authorization. What do you
suggest to indicate scope?


>
>
>
> James Manger
> James.H.Manger at team.telstra.com
> Identity and security team — Chief Technology Office — Telstra
> _______________________________________________
> specs mailing list
> specs at openid.net
> 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)