Sorry OAuth folks: I have mistakingly Cc: all'ed. This is OpenID Connect ID Token stuff and not pertinent to OAuth WG per se nor this discussion which was about the access token. I should have removed the list from Cc:.
I will respond more stuff directly related to the original thread subsequently. 2015-08-19 13:59 GMT+09:00 Mike Jones <michael.jo...@microsoft.com>: > 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:sakim...@gmail.com] > *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 <michael.jo...@microsoft.com>: > > 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:oauth-boun...@ietf.org] *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 <adam.le...@motorolasolutions.com>: > > 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 > OAuth@ietf.org > 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 > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
