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 <[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 in the IANA “JSON > Web Token Claims” registry at > http://www.iana.org/assignments/jwt/jwt.xhtml. > > > > -- 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%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]>: > > 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%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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
