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 <jric...@mit.edu> 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
<sberyoz...@gmail.com> 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
