> I don't see why an opaque scope parameter would create any problems > for a library implementation. Working on such an implementation right > now and opaque scopes are perfectly fine.
I completely agree. In practice this hasn't caused a problem. We discussed the idea of forcing an absolute URI here and whether it had to be the actual resource URI. That doesn't work when the AS uses the same access policy for multiple resources. Opaque seems like a fine proposal to me. >> Comment 3: This isn't the case when the client is presenting a token issued >> by >> another server. I suggest a change to something like the following: "When >> requesting access from the authorization server, the client identifies itself >> using client credentials known to the authorization server." > > What token? The authorization endpoint isn't an OAuth-protected resource. In the case where you present a SAML (or other format) assertion, it is a kind of a protected resource - the resource is an access token. >> This isn't the old testament. No need to look for hidden meaning. The spec >> is about getting access to protected resources, generally dealing with *a* >> protected resource. How resources are segmented is beyond the scope. I think >> it is more useful to talk about it using simpler assumptions - it doesn't >> prevent the more complex use cases. > I think this ties in with the scope parameter. When requesting authorization, > if a client can also pass a scope parameter, then access is granted only > to the resources that accept that scope and not to all resources controlled > by this Authorization Server. This is only a minor wording comment, but I think the idea is significant. The assumption that there is a 1:1 mapping between an AS and a PR seems out of place for the spec. It's easy to imagine that a single AS controls access to many resources (photos, friends, address books, etc.) - this is in fact what happens today. --justin _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
