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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
