On 4/1/10 4:22 PM, Justin Smith wrote: >> 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.
If that's true, then how does the Authorization Server know what scope is appropriate at the Protected Resource? Does inclusion of the scope parameter require a 1:1 mapping between AS and PR, or at least communication between AS and PR? Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
