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
On Mon, Dec 16, 2019 at 10:31 PM Vittorio Bertocci 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
-03 Sec 2.1 has:
"The typ header parameter for a JWT access token MUST be at+jwt. See
the security considerations section for details on the importance of
preventing JWT access tokens to be interpreted as id_tokens."
As previously mentioned in
On Mon, Dec 16, 2019 at 9:20 PM Vittorio Bertocci wrote:
>
> authentication session properties:
>
> Let me try another angle. Say that I perform an authz code grant asking
> for AT, ID_T and RT- obtaining AT', ID_T' and RT'.
> The values of auth_time, acr and amr in AT' will be the same as the
the lines here. If this is the
> intention, it should be clearly stated. Alternatively, remove (or change to
> a SHOULD) the requirement that multi-value `aud` claims must only contain
> aliases for the same resource indicator.
>
>
>
> –
>
> Annabelle Richard Backman
>
&
Hi Torsten!
>
> just to make sure I understood correctly. Are you saying the client has
> credentials but is not authenticated using those in all potential
> scenarios? Can you pls. explain the rationale?
Yes, that's the scenario. In Azure AD you create an app registration that
generates a
Hi Vittorio,
> On 17. Dec 2019, at 05:19, Vittorio Bertocci
> wrote:
>
> In the cases I have seen, the idea is that a client (whose clientID is
> already known to the RS) can obtain tokens thru different grants, some of
> them confidential and others public;
just to make sure I understood
expectation is that each RS should recognize that generic
>> audience. Is this correct? If so it seems to go against the spirit of
>> resource indicators as indicating the target or location of a resource.
>> It’s stretching that definition, at the very least.
>>
>>
>
t the very least.
>
>
>
> But as I said, I’m reading between the lines here. If this is the
> intention, it should be clearly stated. Alternatively, remove (or change to
> a SHOULD) the requirement that multi-value `aud` claims must only contain
> aliases for the same resource indicator.
&g
Dear all,
I finally found the time to push a new draft of the JWT profile for ATs.
This version incorporates the feedback kindly provided by Brian and Aaron
at IETF105.
Unfortunately I didn't have a chance to participate to IETF106, hence we
didn't do much progress since then.
There are still two
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.
Title : JSON Web Token (JWT) Profile for OAuth 2.0 Access
Tokens
Author : Vittorio Bertocci
11 matches
Mail list logo
