Hi Justin
Thanks, may be if a value for that field is not set, then, by default, a
client can use the access tokens against the arbitrary RS servers, as
far as I understand this is what happens by default right now ?
Cheers, Sergey
On 28/11/16 18:47, Justin Richer 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
