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.schanzenb...@aisec.fraunhofer.de> wrote: > > > > On 15. Apr 2019, at 18:20, Sascha Preibisch <saschapreibi...@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.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 > >> > > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
