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.
Thanks, Sascha Am Sa., 13. Apr. 2019 um 09:29 Uhr schrieb Schanzenbach, Martin <martin.schanzenb...@aisec.fraunhofer.de>: > > > > > On 10. Apr 2019, at 19:39, Sascha Preibisch <saschapreibi...@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-sakim...@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-boun...@ietf.org> On Behalf Of Anthony Nadalin > > Sent: Wednesday, April 10, 2019 8:12 PM > > To: Hannes Tschofenig <hannes.tschofe...@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-boun...@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&data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&sdata=ePmwaD%2FHCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&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&data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616357060&sdata=zcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDtlIUH7tS%2Fw%3D&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.schanzenb...@aisec.fraunhofer.de > GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
