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

[Sergey Beryozkin <[e-mail]>]

Hi,
We'll experiment with starting supporting a "resource_uris" extension 
array property - the name is based on a 'resource' indicator property 
from the resource indicators draft, with a '_uris' added given that many 
dynamic registration properties have similar suffixes

Cheers, Sergey
On 29/11/16 10:49, Sergey Beryozkin wrote:
> 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
>>
>