Thanks for the response - feedback inline...
On Wed, May 12, 2010 at 5:09 PM, Manger, James H <
james.h.man...@team.telstra.com> wrote:
> Evan,
>
> > Clients need to know the following in advance:
> > 1. The scope to use to request access to a protected resource
> > 2. The API endpoint to call to access the the protected resource
> >
> > Solving the question of what URL prefixes are valid to send the token
> > to seems like it needs to follow answers for #1 and #2 (or at least #2).
>
> I agree that a client needs #2 to *start* using an API.
> The issue is what the client needs as it follows redirects and links
> through the API and beyond.
>
> > As an example, to support #2 we might want to return JSON
> > configuration about all of the APIs that are available
> > ({'contacts.get': 'http:/...', 'activities.post': 'http://...'}).
> > This would supersede the need for the sites parameter.
>
> I don't like this specific idea of mixing API discover with the credential
> format.
Seems like if it's OK to send a list of valid "sites" for a credential it
should be OK to list the API endpoints.
Also, this discovery could be in a separate process - doesn't have to be
with the token response. The key point is that this discovery covers a lot
of the same grounds as the sites parameter, and it's hard to define
semantics around a sites parameter without understanding the semantics of
scopes and API endpoints.
> It is a web-style approach though: the client follows links in a response.
> Such links in a response will not only occur at this initial point, they can
> appear anywhere in a web-style API. The client needs to know what to do
> (send token or not) at each point that a link appears -- "sites" answers
> this.
Clients need to more about these links (at least the response format). The
mechanism they use to find out about these links - documentation, discovery,
data returned with token request - could also provide the information about
whether a token should be sent to a particular API.
>
>
> > I think this idea relates closely to scopes and probably needs to be
> bound more tightly to the inbound scope parameter. Both identify a set of
> protected resources that can be accessed with the token - one is the
> requested resources, the other is the granted resources.
>
> This is not true.
> Facebook scopes, for instance, are permissions not identities of protected
> resources. If you want (generic) clients to be able to list requested
> resources (by URI?) that needs a separate proposal, and probably can't use
> "scopes".
>
I was using "set of protected resources" to mean a permission.
I should be more concrete about the use cases I see. Let's assume there's an
API where there are two endpoints, each with an associated permission
- contacts.list permission ->
http://contacts.serviceprovider.com/contacts/list
- calendar.get permission ->
http://calendar.serviceprovider.com/calendar/get
If the response to an authorization request includes the authorized scopes
(contacts.list, calendar.get), then the "sites" parameter is redundant.
>
> > In both cases you need to have a way to find a mapping
> > from protected resource identifier -> API endpoint you can call.
>
> Isn't a "protected resource identifier" the URI you GET/POST/PUT/DELETE to?
>
>
>
> P.S. On #1, a client needs an authz URI to send a user to -- knowing the
> scope and a base URI is just one way to build such an authz URI, being given
> the authz URI is another.
>
> --
> James Manger
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
