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] > <mailto:[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 > <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:[email protected] > <javascript:_e(%7B%7D,'cvml','[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://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 <[email protected] > <javascript:_e(%7B%7D,'cvml','[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://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 <[email protected] > <javascript:_e(%7B%7D,'cvml','[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 > <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 > <http://www.iana.org/assignments/jwt/jwt.xhtml>. > > > > -- Mike > > > > From: OAuth [mailto:[email protected] > <javascript:_e(%7B%7D,'cvml','[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%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 <[email protected] > <javascript:_e(%7B%7D,'cvml','[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] <javascript:_e(%7B%7D,'cvml','[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%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/ <http://nat.sakimura.org/> > @_nat_en > > _______________________________________________ > OAuth mailing list > [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> > 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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
