Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Pedro Igor Silva <[e-mail]>]

Nice work Vittorio.

I think the "sub" claim can also be used to reference the client (depending
on the implementation may not necessarily map to the client_id). It might
eventually reference the same entity as the client_id.

In addition to the "sub" claim, does it make sense to explicitly have
the "preferred_username"
claim (section 5.1 of OpenID.Core) as OPTIONAL in Section 2.2 Data Structure
? Isn't this claim a quite common piece of information processed by
resource servers?

Regards.
Pedro Igor

On Mon, Mar 25, 2019 at 2:59 PM Hans Zandbelt <[e-mail]>
wrote:

> Without agreeing or disagreeing: OIDC does not apply here since it is not
> OAuth and an access token is not an id_token.
> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:
>
> "The "sub" (subject) claim identifies the principal that is the
>    subject of the JWT.  The claims in a JWT are normally statements
>    about the subject.  The subject value MUST either be scoped to be
>    locally unique in the context of the issuer or be globally unique.
>    The processing of this claim is generally application specific"
>
> which kind of spells "client" in case of the client credentials grant but
> I also do worry about Resource Servers thinking/acting only in terms of
> users
>
> Hans.
>
> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <[e-mail]>
> wrote:
>
>> IMHO the sub claim should always refer to the user - and nothing else.
>>
>> OIDC says:
>>
>> "Subject - Identifier for the End-User at the Issuer."
>>
>> client_id should be used to identify clients.
>>
>> cheers
>> Dominick
>>
>> On 25.. March 2019 at 05:13:03, Nov Matake ([e-mail]) wrote:
>>
>> Hi Vittorio,
>>
>> Thanks for the good starting point of standardizing JWT-ized AT.
>>
>> One feedback.
>> The “sub” claim can include 2 types of identifier, end-user and client,
>> in this spec.
>> It requires those 2 types of identifiers to be unique each other in the
>> IdP context.
>>
>> I prefer omitting “sub” claim in 2-legged context, so that no such
>> constraint needed.
>>
>> thanks
>>
>> nov
>>
>> On Mar 25, 2019, at 8:29, Vittorio Bertocci <
>> vittorio.bertocci=[e-mail]> wrote:
>>
>> Dear all,
>> I just submitted a draft describing a JWT profile for OAuth 2.0 access
>> tokens. You can find it in
>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
>> remotely). I look forward for your comments!
>>
>> Here's just a bit of backstory, in case you are interested in how this
>> doc came to be. The trajectory it followed is somewhat unusual.
>>
>>    - Despite OAuth2 not requiring any specific format for ATs, through
>>    the years I have come across multiple proprietary solution using JWT for
>>    their access token. The intent and scenarios addressed by those solutions
>>    are mostly the same across vendors, but the syntax and interpretations in
>>    the implementations are different enough to prevent developers from reusing
>>    code and skills when moving from product to product.
>>    - I asked several individuals from key products and services to share
>>    with me concrete examples of their JWT access tokens (THANK YOU Dominick
>>    Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel
>>    Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!
>>    ).
>>    I studied and compared all those instances, identifying commonalities
>>    and differences.
>>    - I put together a presentation summarizing my findings and
>>    suggesting a rough interoperable profile (slides:
>>    https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
>>    <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
>>    ) - got early feedback from Filip Skokan on it. Thx Filip!
>>    - The presentation was followed up by 1.5 hours of unconference
>>    discussion, which was incredibly valuable to get tight-loop feedback and
>>    incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov,
>>    Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there
>>    and contributed generously to the discussion. Thank you!!!
>>    Note: if you were at OSW2019, participated in the discussion and
>>    didn't get credited in the draft, my apologies: please send me a note and
>>    I'll make things right at the next update.
>>    - On my flight back I did my best to incorporate all the ideas and
>>    feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat,
>>    Hannes and above all Brian were all super helpful in negotiating the
>>    mysterious syntax of the RFC format and submission process.
>>
>> I was blown away by the availability, involvement and willingness to
>> invest time to get things right that everyone demonstrated in the process.
>> This is an amazing community.
>> V.
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> [e-mail]
> ZmartZone IAM - www.zmartzone.eu
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>