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

[Justin Richer <[e-mail]>]

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 <[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,
>>     the claim “azp” has already been registered by OpenID Connect
>>     Core at 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:[e-mail]
>>     <javascript:_e(%7B%7D,'cvml','[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 should
>>         probably be using a different claim to reduce the confusion.
>>
>>     John B.
>>
>>         On Aug 19, 2015, at 3:17 AM, Nat Sakimura <[e-mail]
>>         <javascript:_e(%7B%7D,'cvml','[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 ).
>>         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
>>         <[e-mail]
>>         <javascript:_e(%7B%7D,'cvml','[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
>>         azpvalue 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 in the
>>         IANA “JSON Web Token Claims” registry at
>>         http://www.iana.org/assignments/jwt/jwt.xhtml.
>>
>>         -- Mike
>>
>>         *From:*OAuth [mailto:[e-mail]
>>         <javascript:_e(%7B%7D,'cvml','[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://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
>>         <[e-mail]
>>         <javascript:_e(%7B%7D,'cvml','[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
>>         [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
>>         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/
>>         @_nat_en
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> -- 
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth