> From what I see, authorized presenter is a subset of authorized party.
That is also my understanding. Kind Regards Kepeng 发件人: Nat Sakimura <sakim...@gmail.com> 日期: Thursday, 20 August, 2015 9:01 am 至: Mike Jones <michael.jo...@microsoft.com> 抄送: OAuth WG <oauth@ietf.org> 主题: Re: [OAUTH-WG] RS as a client guidance 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 <michael.jo...@microsoft.com>: > 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:oauth-boun...@ietf.org] 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 <jric...@mit.edu> 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 <sakim...@gmail.com> 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<michael.jo...@microsoft.com> さんは書きました: >>>> >>>> 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.o >>>> rg%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg14679.html&data=01%7c01%7cMi >>>> chael.Jones%40microsoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86 >>>> f141af91ab2d7cd011db47%7c1&sdata=3TbSJzfONy8nvH1hDcjGQPmdeen39IJDHk1R99tD7B >>>> E%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.o >>>> rg%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:ve7...@ve7jtb.com] >>>> 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.ie >>>>> tf.org%2fhtml%2fdraft-sakimura-oauth-rjwtprof-05&data=01%7c01%7cMichael.Jo >>>>> nes%40microsoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af9 >>>>> 1ab2d7cd011db47%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 <sakim...@gmail.com> 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.ie >>>>> tf.org%2fhtml%2fdraft-sakimura-oauth-rjwtprof-05&data=01%7c01%7cMichael.Jo >>>>> nes%40microsoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af9 >>>>> 1ab2d7cd011db47%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 <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.ne >>>>> t%2fspecs%2fopenid-connect-core-1_0.html&data=01%7c01%7cMichael.Jones%40mi >>>>> crosoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd >>>>> 011db47%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%40microso >>>>> ft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db >>>>> 47%7c1&sdata=kijVXFcn2du2Ha5xvX%2bTgwohVGOl%2fxmryplQNsWHYzo%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.ie >>>>> tf.org%2fhtml%2fdraft-sakimura-oauth-rjwtprof-05&data=01%7c01%7cMichael.Jo >>>>> nes%40microsoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af9 >>>>> 1ab2d7cd011db47%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 <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%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.sakim >>>>> ura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8fc7f0da91324dd9 >>>>> 570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HNVIwuDJAOWx >>>>> fWyduzov8RK%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.sakim >>>>> ura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8fc7f0da91324dd9 >>>>> 570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HNVIwuDJAOWx >>>>> fWyduzov8RK%2fZKG17xQnYZVFWv94oqY%3d> >>>>> @_nat_en >>>>> _______________________________________________ >>>>> 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%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.sakimu >>>> ra.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8fc7f0da91324dd957 >>>> 0908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HNVIwuDJAOWxfWy >>>> duzov8RK%2fZKG17xQnYZVFWv94oqY%3d> >>>> @_nat_en >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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.o >>> rg%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com >>> %7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&s >>> data=LjPpTGV4iGtx1SQKfz%2bsYv3ZdxEqyoTXrCd1BCqvMlw%3d> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
