And while we are at the history, my original draft idea (on my blog) on Aug. 3, 2012 had "nau" -- named authorized user. So, three of us came up with a similar idea independently with more or less the same idea, and it was unified to azp -- authorized presenter.
The name change to authorized party took later to expand the meaning of it. >From what I see, authorized presenter is a subset of authorized party. 2015-08-20 9:52 GMT+09:00 Mike Jones <[email protected]>: > Just to complete the history, I believe the original Google deployed claim > name for this purpose was “cid” (Client ID) – a name that seemed ripe with > ambiguity. > > > > *From:* OAuth [mailto:[email protected]] *On Behalf Of *John Bradley > *Sent:* Wednesday, August 19, 2015 5:50 PM > *To:* Justin Richer > > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] RS as a client guidance > > > > Ah yes, Now I recall that we had Google change the claim once to azp and > then discussed changing it again once we decided that azp was not the > necessarily the presenter presenter. That was what we decided was too > cruel getting them to change the name again for something that they then > had released in production. That caused us to re-acrom “azp”. > > > > John B. > > > > On Aug 19, 2015, at 9:39 PM, Justin Richer <[email protected]> wrote: > > > > Just want to clear up some history: "azp" did not come from any existing > claims from Google or otherwise. I very clearly recall proposing that we > name it "prn" for "presenter", and Mike told me not to be evil[1] because > we had just changed "prn" (for "principal") in the ID token to "sub" in > order to match the more generic JWT. John suggested "a-zed-p" in the same > discussion. As such, it clearly was "authorized presenter" in the first > take, then it got widened/shifted a little bit in the final definition for > reasons I never quite followed (nor cared much about at the time). > > -- Justin > > [1] Being told "don't be evil" by a Microsoft employee remains one of my > proudest achievements. > > On 8/19/2015 8:35 PM, John Bradley wrote: > > It could, but I remain to be convinced that would be a good idea. “azp” > came from a existing Google claim, I am not attached to the name. > > > > John B. > > On Aug 19, 2015, at 9:29 PM, Nat Sakimura <[email protected]> wrote: > > > > Well, the abstract meaning is the same, but the practical implications and > interpretation can vary within the boundaries depending on the context. > > > > A jku is a URI of a cryptographical key, which can be a uri of a signing > key or encryption key depending on the context. Similarly the azp in an ID > Token and an Access Token can share the same abstract concept while the > concrete meaning in that particular concept can vary. > > 2015年8月20日木曜日、Mike Jones<[email protected]> さんは書きました: > > Let me second John’s point that we shouldn’t have two different > definitions for “azp”. As I wrote in my friendly review of > draft-sakimura-oauth-rjwtprof-04 at > http://www.ietf.org/mail-archive/web/oauth/current/msg14679.html > <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg14679.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3TbSJzfONy8nvH1hDcjGQPmdeen39IJDHk1R99tD7BE%3d>, > the claim “azp” has already been registered by OpenID Connect Core 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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kijVXFcn2du2Ha5xvX%2bTgwohVGOl%2fxmryplQNsWHYzo%3d> > and so cannot be re-registered. Given that I believe the intended > semantics are the same, please cite the existing definition in rjwtprof, > rather than repeating it or revising it. > > > > Thanks, > > -- Mike > > > > *From:* John Bradley [mailto:[email protected]] > *Sent:* Wednesday, August 19, 2015 11:05 AM > *To:* Nat Sakimura > *Cc:* Mike Jones; OAuth WG > *Subject:* Re: [OAUTH-WG] RS as a client guidance > > > > Having two azp claims with slightly different definitions is not a good > way to go, both access tokens and id_tokens are JWT. > > For better or worse the claim was defined for bearer tokens where it was > only the identity of the requester that was able to be confirmed by the > token endpoint. > > It supported a simple use case where a refresh token is used by client A > to use as an assertion at AS B. > > In the simplest 3 party sase the requester of the token and the presenter > of the token are the same. However in some situations they are not the > same. > > The important thing was to allow the “aud” recipient of the token to be > able to differentiate a token that it requested from a a token that a 3rd > party requested and presented to it. > > > > The “azp” should probably be left as it is and not tied to proof of > possession/ binding the token to the presenter. > > There was a lot of debate and back and forth on azp at the time, the main > reason to include it was to warn normal Connect clients that JWT containing > that azp claim need to have it’s value be them or someone they know and > trust that can request assertions for them. That was because we knew that > token containing that claim exist in the wild using that claim. > > > > 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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VTIpHaqCd%2fmxrEfxKD8i5h5AzeWV5rsZC05oVOv73SA%3d> > should > probably be using a different claim to reduce the confusion. > > > > John B. > > > > > > On Aug 19, 2015, at 3:17 AM, Nat Sakimura <[email protected]> wrote: > > > > So, Mike, > > > > Authorized Presenter is a defined term in *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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VTIpHaqCd%2fmxrEfxKD8i5h5AzeWV5rsZC05oVOv73SA%3d> > ). > It is used in the context of OAuth 2.0 Access Token, not a claim in ID > Token of OpenID Connect. > > > > Nat > > > > 2015-08-19 11:44 GMT+09:00 Mike Jones <[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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3e6US9sxQoQVejthrxO%2fo%2bvdltE%2fBUj1NUSMBk6vOS0%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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kijVXFcn2du2Ha5xvX%2bTgwohVGOl%2fxmryplQNsWHYzo%3d> > . > > > > -- Mike > > > > *From:* OAuth [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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VTIpHaqCd%2fmxrEfxKD8i5h5AzeWV5rsZC05oVOv73SA%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]>: > > 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] > 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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LjPpTGV4iGtx1SQKfz%2bsYv3ZdxEqyoTXrCd1BCqvMlw%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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HNVIwuDJAOWxfWyduzov8RK%2fZKG17xQnYZVFWv94oqY%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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HNVIwuDJAOWxfWyduzov8RK%2fZKG17xQnYZVFWv94oqY%3d> > @_nat_en > > _______________________________________________ > OAuth mailing list > [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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LjPpTGV4iGtx1SQKfz%2bsYv3ZdxEqyoTXrCd1BCqvMlw%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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HNVIwuDJAOWxfWyduzov8RK%2fZKG17xQnYZVFWv94oqY%3d> > @_nat_en > > > > > > > > > _______________________________________________ > > OAuth mailing list > > [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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LjPpTGV4iGtx1SQKfz%2bsYv3ZdxEqyoTXrCd1BCqvMlw%3d> > > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
