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/1
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 RS
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 token
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 th
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 wrote:
>
> Hi
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 r
