Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt

[Brian Campbell <[e-mail]>]

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 <[e-mail]>
wrote:

>
>
> On Mon, Dec 16, 2019 at 10:31 PM Vittorio Bertocci <Vittorio=
> [e-mail]> 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._