> 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
