Re: [OAUTH-WG] Dynamic client registration and the audience (resource) indicators

[Sergey Beryozkin <[e-mail]>]

Hi John, All

I've been alway thinking that the reason an audience can be an array (as 
indicated for ex by the JWT spec, etc) is because a client application 
may need to talk to more than one RS in order to complete a single 
action for the current user (ex, the client will not talk to either RS1 
or RS2 but first to RS1 and then will complete the action by talking to 
RS2).

Why else would a JWT access token have an array of audience values ?
https://tools.ietf.org/html/rfc7519#section-4.1.3

I agree the resource indicators can help on its own - in case no 
audiences for a given client have been pre-registered or as you 
suggested - to point to a specific resource at the runtime, with this 
(resource) URI being validated against the pre-registered values.

But also, pre-registering a single audience during the client 
registration (dynamic or static) can minimize the need to use the 
resource indicators at the runtime.

I did not quite understand what you were explaining about registering 
RSs with the client - I guess that client will know in advance which 
RS(s) it will need to talk to do its work,

Many thanks, Sergey




On 28/11/16 22:58, John Bradley wrote:
> To make something like this work with a loose coupling between the RS and AS the format of the AT would also need to be specified.
>
> To this point the WG has avoided standardizing AT.
>
> Most AS probably believe they know what RS the token is going to be used at based on scopes.
> Taking those tokens and using them at other RS is arguably at-least out of scope or arguably not allowed by the current specs.
>
> People are perhaps abusing the specs and sending AT to RS that are not properly audienced and can be replayed between RS.
> This is really bad from a security perspective with bearer tokens.
>
> I do however see a valid use case.
>
> Registering RS with the client is not a bad idea, however if you register more than one without the client saying at runtime what RS the token is for they can still be replayed.
> The client depending on design could still be tricked by a RS or something else to get a token audienced to a different RS if the AS dosen't know where the client is sending the token.
>
> I don’t think registering RS gets around the need for the resource indicator draft https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators
>
> Typically we have thought about a tight coupling between the RS and AS,  but now it seems people are putting more of the intelligence/burden on the the client.
>
> in a more dynamic system the RS might provide a list of AS that it accepts tokens form and the client might dynamically register with one of them.
>
> I suspect Sergey’s AS is doing something in between.
>
> I am hesitant to pick off just dynamic registration as there are a number of interrelated issues that need to be thought through to prevent security issues.
>
> John B.
>
>
>
>
>
>
>> On Nov 28, 2016, at 3:47 PM, Justin Richer <[e-mail]> wrote:
>>
>> I would consider that a totally reasonable extension. You will need to define what the behavior is if the client doesn’t provide a value for that field: is there a default? Are there no resources available to the client?
>>
>> — Justin
>>
>>> On Nov 28, 2016, at 12:21 PM, Sergey Beryozkin <[e-mail]> wrote:
>>>
>>> Hi All
>>>
>>> Our AS allows for the manual client registration with the UI offering an option to assign the audience/resource URIs to a given Client registration with all the associated future access tokens inheriting them.
>>>
>>> The client will not have to follow the resource indicator registration as recommended at [1] - the administrator who registers the clients sets the audiences.
>>>
>>> We'd like to achieve the same with the dynamic client registration but my colleague noted the client metadata in the dynamic registration request has no 'audience' property.
>>>
>>> We will consider supporting either an 'audience' or 'resource' property - does it sound reasonable ?
>>>
>>> By the way, as far as [1] is concerned, should a 'resource' property support an array of audiences ? (To support a case a client needed to talk to several RSs to complete a given action)
>>>
>>> Thanks, Sergey
>>>
>>> [1] https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>