The “azp” description was changed after the in-person OpenID Connect working group meeting at Google on 6-May-13, in which we agreed that “azp” would be used to represent the issued-to information, and that the claim would be named “Authorized Party”. See the meeting notes at http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130506/003466.html, including attachment http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0005.jpg, which documents that we decided to represent issued-to information with “azp” and attachment http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0006.jpg, which documents that the “azp” claim is to represent an “Authorized Party”. We also decided to make “azp” single-valued there, where it had previously been multi-valued.
Breno de Medeiros and Naveen Agarwal of Google were at the meeting, and in fact, were behind many of these changes, which is significant, since they were the inventors of this functionality. They concurred with and participated developing these resolutions previously open issues about the meanings of “aud” and “azp”. Afterwards, the meeting notes were sent to the working group mailing list for review there and no objections were raised. There’s no mystery. Furthermore, all of this text went through both the 45 day Implementer’s Draft 2 public review period announced at http://openid.net/2013/06/07/review-of-proposed-openid-connect-implementers-drafts/ and the 60 day Final Specification public review period announced at http://openid.net/2013/12/20/review-of-proposed-final-openid-connect-specifications-and-implementers-drafts/, and no objections were raised during those reviews either. People seemed happy with the resolution arrived at during the working group meeting. So in conclusion, it would probably be less confusing to all concerned if you were to stop referring to “azp” as “authorized presenter” or ascribing those semantics to it (whatever those may be). Sometime before Implementer’s Draft 2 of OpenID Connect that terminology was used, but the working group changed that and the meaning of “azp” by consensus in May 2013 and it’s been that way ever since. Trying to overload “azp” with a different meaning than what’s in the standard seems counterproductive, which is why I wrote my original note of clarification. Thanks for taking this into account. Best wishes, -- Mike From: Nat Sakimura [mailto:[email protected]] Sent: Tuesday, August 18, 2015 9:04 PM To: Mike Jones Cc: Adam Lewis; OAuth WG Subject: Re: [OAUTH-WG] RS as a client guidance I have dug into it why it ended up like that. The approved text per the ticket #712 and #830 was: azp OPTIONAL. Authorized Presenters. This member identifies OAuth 2.0 Client(s) and potentially other parties authorized to use this ID Token as an assertion of the identity of the ID Token's subject at the ID Token's audiences. If present, it MUST contain the client_id or other identifiers for all Authorized Presenters. The issuer is not to be listed as an Authorized Presenter. This Claim is only needed when the party requesting the ID Token is not the same as the sole audience of the ID Token. It MAY be included even when the Authorized Presenter is the same as the sole audience. Authorized Presenter values should be verified by the participants, however the mechanisms for validating azp values are beyond the scope of this specification. In the general case, the azp value is an array of case sensitive strings, each containing a StringOrURI value. In the special case when the ID Token has one authorized presenter, the azp value MAY be a single case sensitive string containing a StringOrURI value. It got changed to the one that Mike sited without any ticket. It is a mystery. Nat 2015-08-19 11:44 GMT+09:00 Mike Jones <[email protected]<mailto:[email protected]>>: Just as a point of clarification, the definition of the “azp” claim is not “authorised presenter”. At least as defined by OpenID Connect, its definition is: azp OPTIONAL. Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This Claim is only needed when the ID Token has a single audience value and that audience is different than the authorized party. It MAY be included even when the authorized party is the same as the sole audience. The azp value is a case sensitive string containing a StringOrURI value. A reference to this definition is registered by OpenID Connect Core http://openid.net/specs/openid-connect-core-1_0.html<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c718a77de87a54312a76b08d2a84b33cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rak35YM4lwq191Sbx0G9feviUU2ltCxhDS3auYuA6ew%3d> in the IANA “JSON Web Token Claims” registry at http://www.iana.org/assignments/jwt/jwt.xhtml<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.iana.org%2fassignments%2fjwt%2fjwt.xhtml&data=01%7c01%7cMichael.Jones%40microsoft.com%7c718a77de87a54312a76b08d2a84b33cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rvGHkfj1Iie4BTStOyqzF6zfUESvID3JR3%2bkKQZel7w%3d>. -- Mike From: OAuth [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Nat Sakimura Sent: Tuesday, August 18, 2015 7:37 PM To: Adam Lewis Cc: OAuth WG Subject: Re: [OAUTH-WG] RS as a client guidance It is not directly, but Sender Constrained JWT for OAuth 2.0 ( https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-sakimura-oauth-rjwtprof-05&data=01%7c01%7cMichael.Jones%40microsoft.com%7cdac2bd4946594ba7f4ff08d2a83f23cf%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DhL9%2bp5Ml32P6%2fdaAQHHkho1yCsbq2W0M4WNrwgo1zo%3d> ) talks about a model that allows it. In essence, it uses a structured access token that is sender constrained. It as a claim "azp" which stands for authorised presenter. To be used, the "client" has to present a proof that it is indeed the party pointed by "azp". In your case, the native mobile app obtains the structured access token with "azp":"the_RS". Since "azp" is not pointing to the mobile app, the mobile app cannot use it. The mobile app then ships it to the RS. The RS can now use it since the "azp" points to it. In general, shipping a bearer token around is a bad idea. If you want to do that, I think you should do so with a sender constrained token. Nat 2015-08-13 2:01 GMT+09:00 Adam Lewis <[email protected]<mailto:[email protected]>>: Hi, Are there any drafts that discuss the notion of an RS acting as a client? I'm considering the use case whereby a native mobile app obtains an access token and sends it to the RS, and then the RS uses it to access the UserInfo endpoint on an OP. It's a bearer token so no reason it wouldn't work, but obviously it is meant to be presented by the client and not the RS. Curious to understand the security implications of this, read on any thoughts given to this, or to know if it's an otherwise accepted practice. tx adam _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7cdac2bd4946594ba7f4ff08d2a83f23cf%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=eM%2f2nMY4YEca%2fyZtl6K4f4pRceNCHt1sF7v9ufZ7qgk%3d> -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7cdac2bd4946594ba7f4ff08d2a83f23cf%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2x5%2f9bLJnUcMdOFrYWIk4G0BIwp8ytDK2LNx2BQuTtk%3d> @_nat_en -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c718a77de87a54312a76b08d2a84b33cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=YF1hbON1WremXC%2blR0N43pDiBVr%2fjhBbAieEDtKkv1E%3d> @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
