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:[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 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]<mailto:[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 ). 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]<mailto:[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]<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]<mailto:[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]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
