But there's more going on with aud that needs to be looked at and/or wasn't
updated.
I think this
"The aud
claim MAY include a list of individual resource indicators if they
are all aliases referring to the same requested resource known by
the authorization server."
should be removed from 2.2.
Resource Indicators is about how the client conveys the target to the AS
and says " The authorization server may use the exact 'resource' value as
the audience or it may map from that value to a more general URI or
abstract identifier for the given resource". The following from sec 3 is
more restrictive / prescriptive, which seems to reach beyond the scope of
the JWT access token profile.
"If the request includes a resource parameter (as defined in
[ResourceIndicators]), the resulting JWT access token aud claim MUST
have the same value as the resource parameter in the request."
And sec 4 also has talk of aliases.
" 4. The resource server MUST validate that the aud claim contains the
resource indicator value corresponding to the identifier the
resource server expects for itself. The aud claim MAY contain an
array with more than one element. The JWT access token MUST be
rejected if aud does not list the resource indicator of the
current resource server as a valid audience, or if it contains
additional audiences that are not known aliases of the resource
indicator of the current resource server.
I'd suggest deleting everything after the comma.
If you really want to limit things to a single aud value (and my
understanding is that you do), maybe just place the restriction on the AS
to only issue with a single aud value.
On Wed, Dec 18, 2019 at 2:30 PM Brian Campbell <bcampb...@pingidentity.com>
wrote:
>
>
> On Mon, Dec 16, 2019 at 10:31 PM Vittorio Bertocci <Vittorio=
> 40auth0....@dmarc.ietf.org> wrote:
>
>> Re: aliases, I see where the confusion is coming from!
>> I updated the request section, but the session 2.2 data structure still
>> mentions the aliases. That should be cleaned up as well.
>> In any case the intent was always to only allow a singe resource per AT,
>> the alias list was only for helping in cases where an AS identifies the
>> same resource thru multiple IDs and the actual aud value depends on what ID
>> the client requested. However we discussed this with Brian and he convinced
>> me that it was just too ambiguous- your remark reinforces that impression.
>> I’ll clean up 2.2 and eliminate references to aliases from there as well.
>> Thanks!
>>
>
> Yes, please clean up sec 2.2.
>
--
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited. If you have
received this communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments from your
computer. Thank you._
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
