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

[Vittorio Bertocci <[e-mail]>]

Thank you Bertrand for your comments and kind words!
Inline

>  In addition to the "sub" claim (I agree it should only relate to the end
> user, not the client_id),

See the reply to Dominick & Hans on this. Do you have specific case/attack
in mind?

I think the scope claim should be mentioned as OPTIONAL in §2.2 (it's
> already mentioned in other parts of the draft)

Mmh, let me clarify... the fact that the scope soemtrimes doesn;t show up
doesn;t automatically mean it's optional. Per the current formulation, I am
suggesting that when *scope *is present in the request, a *scope*
claim is *required
(*hence not optional*) *in the resulting token. When scope isn't present in
the incoming request, I didn't go all the way to explicitly disallow it but
it doesn't seem to be necessary in the resulting token. What do you think?

- Should we mention security recommendation on the JWT (like DO NOT USE
> alg="none") and maybe refer to
> *https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-02.html*
> <https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-02.html> ?

That is an excellent idea. Thank you!

- Should we mention the "act" claim defined by Token Exchange as a possible
> claim for JWT access tokens?

My bias would be to keep the set of things we mention in the profile to the
essential of what has been observed in concrete use, to keep the cognitive
burden of consuming the spec to the bare minimum. Currently there's no
language reminding the reader that they can add any extra claims they like,
but that should be true by default for all those specs. How strongly do you
feel about the value of explicitly mentioning "act" already in v1 of the
profile?

- any reason to rely on RFC 7662 (Introspection) for the token format? I
> see that the "nbf" (not before) claim is defined there

Do you mean "not rely" by any chance?
The current set of claims in the layout derives from observing what's most
commonly used, combined with the fact that many JWT validators used in the
wild are geared to work with id_tokens (hence more likely to work as is
with the new profile, always remembering the at+typ measure).
In particular, nbf was brought up during OSW2019 and, given its relatively
rare occurrence (only AAD and IS had it), I was advised to improve the
signal/noise ratio and cut it.


On Mon, Mar 25, 2019 at 7:55 AM CARLIER Bertrand <
[e-mail]> wrote:

> Hi Vittorio,
>
> Very nice work !
>
> Here are a few ideas:
> - In addition to the "sub" claim (I agree it should only relate to the end
> user, not the client_id), I think the scope claim should be mentioned as
> OPTIONAL in §2.2 (it's already mentioned in other parts of the draft)
> - Should we mention security recommendation on the JWT (like DO NOT USE
> alg="none") and maybe refer to
> *https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-02.html*
> <https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-02.html> ?
> - Should we mention the "act" claim defined by Token Exchange as a
> possible claim for JWT access tokens?
> - any reason to rely on RFC 7662 (Introspection) for the token format? I
> see that the "nbf" (not before) claim is defined there
>
> Regards,
> --
>
> *Bertrand CARLIER *
>
> *From:* OAuth <[e-mail]> *On Behalf Of *Vittorio Bertocci
> *Sent:* lundi 25 mars 2019 00:29
> *To:* IETF oauth WG <[e-mail]>
> *Subject:* [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>
> 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/*
> <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.
>
> The information transmitted in the present email including the attachment
> is intended only for the person to whom or entity to which it is addressed
> and may contain confidential and/or privileged material. Any review,
> retransmission, dissemination or other use of, or taking of any action in
> reliance upon this information by persons or entities other than the
> intended recipient is prohibited. If you received this in error, please
> contact the sender and delete all copies of the material.
>
> Ce message et toutes les pièces qui y sont éventuellement jointes sont
> confidentiels et transmis à l'intention exclusive de son destinataire.
> Toute modification, édition, utilisation ou diffusion par toute personne ou
> entité autre que le destinataire est interdite. Si vous avez reçu ce
> message par erreur, nous vous remercions de nous en informer immédiatement
> et de le supprimer ainsi que les pièces qui y sont éventuellement jointes.
>