Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

Thanks you all for your comments.

Based on this feedback, we think that there is good support for this to
become a WG document.

*Vittorio*,

Please, go ahead and submit a new WG draft.

Regards,
 Rifaat & Hannes

On Tue, Apr 16, 2019 at 4:13 AM Schanzenbach, Martin <
martin.schanzenbach@aisec.fraunhofer.de> wrote:

>
>
> > On 15. Apr 2019, at 18:20, Sascha Preibisch <saschapreibisch@gmail.com>
> wrote:
> >
> > Thanks, Martin!
> >
> > I understand. I just think it is difficult to get this adopted if
> > clients now have to include the target resource in their request in
> > order to place that into the 'aud' field. Unless the client has
> > somehow registered its intended protected resources beforehand the
> > authorization server cannot set an appropriate value if it was not
> > passed in as a request parameter.
>
> Yes, I think this is how it was supposed to work anyway even without JWTs.
> The client uses the "scope" parameter to indicate what it needs access to.
> The AS needs to make a decision in accordance with the RO what access
> token to issue (i.e. which RS to grant access to).
> The scope does not need to be the full RS URI. It is domain-specific what
> RSes a scope parameter maps to. Nothing the spec can do here, really.
>
> BR
> Martin
>
> >
> > Thanks,
> > Sascha
> >
> > Am Sa., 13. Apr. 2019 um 09:29 Uhr schrieb Schanzenbach, Martin
> > <martin.schanzenbach@aisec.fraunhofer.de>:
> >>
> >>
> >>
> >>> On 10. Apr 2019, at 19:39, Sascha Preibisch <saschapreibisch@gmail.com>
> wrote:
> >>>
> >>> I am late in the game, but not too late I hope.
> >>>
> >>> I would like to see 'aud' be the requesting client_id. For identifying
> the the target resource, a 'resource' claim should be introduced. I am also
> suggesting to not introduce 'typ: at+jwt'. It is simply a jwt and the
> validation process will show if it is an access_token or not.
> >>
> >> "aud = client_id" would mean that, by definition, the JWT must not be
> presented to any other entity than the client. This makes only sense for
> the ID Token in OIDC I think.  OTOH, defining a JWT which can be presented
> by the client to the RS is the whole point of this draft.
> >> Also, the reason why it makes sense to introduce a new type is that an
> OIDC ID Token _could_ be mistaken for an AT (which it isn't).
> >> IMO it might even make sense to encourage the OIDC spec to change to
> jwt+id or something by extending the JWT spec.
> >>
> >> I also support the adoption.
> >>
> >>>
> >>> Last but not least, 'aud' (as resource identifier) should not be
> required. Requiring that, and the requested resource in the the token
> request, will require existing clients to be updated. Introducing jwt
> access_token should be transparent to clients.
> >>>
> >>> Thanks,
> >>> Sascha
> >>>
> >>>
> >>> On Wed., Apr. 10, 2019, 06:41 n-sakimura, <n-sakimura@nri.co.jp>
> wrote:
> >>> +1
> >>>
> >>> For that matter, explicit typing is good and I am a bit ambivalent on
> the use of `sub`.
> >>>
> >>> Also, I need to add the 4th consideration: Although the current
> privacy consideration is stating about the encryption, it is in relation to
> the end user exposure. In fact, the by-value access token when involving
> some PII is by definition leaking information and violating the data
> minimization principle. This should be clearly delineated. My gut feeling
> is that it should be encrypted unless it is certain that it does not
> include sensitive PII as judging whether a claim may form a PII is too hard
> for an average developer..
> >>>
> >>> -----Original Message-----
> >>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Anthony Nadalin
> >>> Sent: Wednesday, April 10, 2019 8:12 PM
> >>> To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; oauth@ietf.org
> >>> Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access
> Tokens
> >>>
> >>> I support adoption of this draft as a working group document with the
> following caveats:
> >>>
> >>> 1. These are not to be used as ID Tokens/authentication tokens 2. The
> privacy issues must be addressed 3. Needs to be extensible, much like
> ID-Token, can't be 100% fixed
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Hannes Tschofenig
> >>> Sent: Monday, April 8, 2019 10:07 AM
> >>> To: oauth@ietf.org
> >>> Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access
> Tokens
> >>>
> >>> Hi all,
> >>>
> >>> this is the call for adoption of the 'JWT Usage in OAuth2 Access
> Tokens'  document following the positive feedback at the last IETF meeting
> in Prague.
> >>>
> >>> Here is the document:
> >>>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&amp;data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&amp;sdata=ePmwaD%2FHCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&amp;reserved=0
> >>>
> >>> Please let us know by April 22nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth working
> group.
> >>>
> >>> Ciao
> >>> Hannes & Rifaat
> >>>
> >>> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616357060&amp;sdata=zcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDtlIUH7tS%2Fw%3D&amp;reserved=0
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >> Martin Schanzenbach
> >> Fraunhofer AISEC
> >> Department Service & Application Security
> >> Parkring 4, 85748 Garching near Munich (Germany)
> >> Tel: +49 89 3229986-193
> >> martin.schanzenbach@aisec.fraunhofer.de
> >> GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0
> >>
>
>
> Martin Schanzenbach
> Fraunhofer AISEC
> Department Service & Application Security
> Parkring 4, 85748 Garching near Munich (Germany)
> Tel: +49 89 3229986-193
> martin.schanzenbach@aisec.fraunhofer.de
> GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>