Re: [OAUTH-WG] RS as a client guidance

[John Bradley <[e-mail]>]

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 <[e-mail]> 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 < <mailto:[e-mail]>[e-mail] <mailto:[e-mail]>> 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<[e-mail] <mailto:[e-mail]>> さんは書きました:
>>> 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>http://www.ietf.org/mail-archive/web/oauth/current/msg14679.html <http://www.ietf.org/mail-archive/web/oauth/current/msg14679.html>, the claim “azp” has already been registered by OpenID Connect Core at http://www.iana.org/assignments/jwt/jwt.xhtml <http://www.iana.org/assignments/jwt/jwt.xhtml> 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: <javascript:_e(%7B%7D,'cvml','[e-mail]');>[e-mail] <mailto:[e-mail]>] 
>>> 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://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05 <https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05> should probably be using a different claim to reduce the confusion.
>>> 
>>>  
>>> John B.
>>> 
>>>  
>>>  
>>> On Aug 19, 2015, at 3:17 AM, Nat Sakimura < <javascript:_e(%7B%7D,'cvml','[e-mail]');>[e-mail] <mailto:[e-mail]>> 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://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05 <https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05> ). 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 < <javascript:_e(%7B%7D,'cvml','[e-mail]');>[e-mail] <mailto:[e-mail]>>:
>>> 
>>> 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 <http://openid.net/specs/openid-connect-core-1_0.html> in the IANA “ <>JSON Web Token Claims” registry athttp://www.iana.org/assignments/jwt/jwt.xhtml <http://www.iana.org/assignments/jwt/jwt.xhtml>.
>>> 
>>>  
>>>                                                             -- Mike
>>> 
>>>  
>>> From: OAuth [mailto: <javascript:_e(%7B%7D,'cvml','[e-mail]');>[e-mail] <mailto:[e-mail]>] 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://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>https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05 <https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05> )
>>> 
>>> 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 < <javascript:_e(%7B%7D,'cvml','[e-mail]');>[e-mail] <mailto:[e-mail]>>:
>>> 
>>> 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
>>>  <javascript:_e(%7B%7D,'cvml','[e-mail]');>[e-mail] <mailto:[e-mail]>
>>>  <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>https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> 
>>> 
>>>  
>>> --
>>> 
>>> Nat Sakimura (=nat)
>>> 
>>> Chairman, OpenID Foundation
>>>  <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>http://nat.sakimura.org/ <http://nat.sakimura.org/>
>>> @_nat_en
>>> 
>>> 
>>> 
>>>  
>>> --
>>> 
>>> Nat Sakimura (=nat)
>>> 
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/ <http://nat.sakimura.org/>
>>> @_nat_en
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>  
>>> 
>>> 
>>> -- 
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/ <http://nat.sakimura.org/>
>>> @_nat_en
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>