Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[George Fletcher <[e-mail]>]

I get your 1st party use case and if you think about a company that 
might have multiple endpoints on different domains that provide API 
services all invoked by a mobile app... requiring the mobile app to 
effectively downscope (or resource indicator bind) tokens means a lot of 
chatter between the mobile app to the AS to obtain appropriate tokens. 
And all this over a connection that does have latency issues.

That said, having a single token that is authorized to access all those 
services has it's own risks.

I'm not sure about a structure like...
    https://user.example.com
       scope: profile
    https://mail.example.com
       scope: mail-write
    https://cal.example.com
       scope: calendar-write

User Managed Access (UMA) [1] explicitly defines this structure but it's 
not embedded in the UMA access token.

[1] 
https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html#permission-endpoint

I suppose a need to support multiple audiences within a given access 
token kind of necessitates the need to bind the scopes with the 
audience/resource.

On 4/4/19 1:34 PM, Vittorio Bertocci wrote:
>
>     I think for most implementations this would amount to... define an
>     audience that covers all the resource services where the access
>     token can be returned and set that as the audience (e.g.
>     urn:x-mydomain:apis). Which is perfectly legal but maybe not in
>     the spirit of the spec:) I am receiving feedback from developers
>     that binding access tokens narrowly to the resource where they
>     will be presented is concerning from a chattiness perspective
>     (latency issues) and general load on the deployed AS infrastructure.
>
> This is an interesting point. In my experience, the main boundary used 
> to define a resource is either reflecting an underlying, *actual* 
> resource that exists independently of the API facade slapped on top of 
> it (say a VM) or it is the context within a certains et of scopes 
> makes sense (say an API facading access to a bunch of documents).
> Some of that criterion is reflected in the rationale for sigle value 
> audiences. Do you think it should be made more explicit? Perhaps in a 
> dedicated section?
[rest of thread snipped]