And while we are at the history, my original draft idea (on my blog)
on Aug. 3, 2012 had "nau" -- named authorized user.
So, three of us came up with a similar idea independently with more or
less the same idea, and it was unified to azp -- authorized presenter.
The name change to authorized party took later to expand the meaning
of it.
From what I see, authorized presenter is a subset of authorized party.
2015-08-20 9:52 GMT+09:00 Mike Jones <[email protected]
<mailto:[email protected]>>:
Just to complete the history, I believe the original Google
deployed claim name for this purpose was “cid” (Client ID) – a
name that seemed ripe with ambiguity.
*From:*OAuth [mailto:[email protected]
<mailto:[email protected]>] *On Behalf Of *John Bradley
*Sent:* Wednesday, August 19, 2015 5:50 PM
*To:* Justin Richer
*Cc:* OAuth WG
*Subject:* Re: [OAUTH-WG] RS as a client guidance
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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[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
<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg14679.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3TbSJzfONy8nvH1hDcjGQPmdeen39IJDHk1R99tD7BE%3d>,
the claim “azp” has already been registered by OpenID
Connect Core at
http://www.iana.org/assignments/jwt/jwt.xhtml
<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.iana.org%2fassignments%2fjwt%2fjwt.xhtml&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kijVXFcn2du2Ha5xvX%2bTgwohVGOl%2fxmryplQNsWHYzo%3d>
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]
<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
<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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VTIpHaqCd%2fmxrEfxKD8i5h5AzeWV5rsZC05oVOv73SA%3d>
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
<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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VTIpHaqCd%2fmxrEfxKD8i5h5AzeWV5rsZC05oVOv73SA%3d>
).
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 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
<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3e6US9sxQoQVejthrxO%2fo%2bvdltE%2fBUj1NUSMBk6vOS0%3d>
in the IANA “JSON Web Token Claims” registry at
http://www.iana.org/assignments/jwt/jwt.xhtml
<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.iana.org%2fassignments%2fjwt%2fjwt.xhtml&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kijVXFcn2du2Ha5xvX%2bTgwohVGOl%2fxmryplQNsWHYzo%3d>.
-- 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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VTIpHaqCd%2fmxrEfxKD8i5h5AzeWV5rsZC05oVOv73SA%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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LjPpTGV4iGtx1SQKfz%2bsYv3ZdxEqyoTXrCd1BCqvMlw%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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HNVIwuDJAOWxfWyduzov8RK%2fZKG17xQnYZVFWv94oqY%3d>
@_nat_en
--
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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HNVIwuDJAOWxfWyduzov8RK%2fZKG17xQnYZVFWv94oqY%3d>
@_nat_en
_______________________________________________
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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LjPpTGV4iGtx1SQKfz%2bsYv3ZdxEqyoTXrCd1BCqvMlw%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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HNVIwuDJAOWxfWyduzov8RK%2fZKG17xQnYZVFWv94oqY%3d>
@_nat_en
_______________________________________________
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%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LjPpTGV4iGtx1SQKfz%2bsYv3ZdxEqyoTXrCd1BCqvMlw%3d>
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
