I agree on "I am also suggesting to not introduce 'typ: at+jwt'".
Both regarding practical considerations and RFC7519 (5.1): "This is intended for use by the JWT application when values that are not JWTs could also be present in an application data structure that can contain a JWT object; the application can use this value to disambiguate among the different kinds of objects that might be present. It will typically not be used by applications when it is already known that the object is a JWT" Introducing the "+"-pattern for typ will probably lead to unintended usage in the future. /dag tor. 11. apr. 2019 kl. 19:56 skrev Sascha Preibisch < saschapreibi...@gmail.com>: > 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. > > 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 > <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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
