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. 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.
> 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".
> 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
