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. 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. > 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. James Manger [EMAIL PROTECTED] Identity and security team — Chief Technology Office — Telstra _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
