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

From: Adam Lewis <[email-masked]>
Date: Wed, 12 Aug 2015 12:01:25 -0500

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

---

From: George Fletcher <[email-masked]>
Date: Wed, 12 Aug 2015 14:27:17 -0400

Hi Adam,

If all the RS needs is say the "sub" field for the user, then you might 
want to look at the introspection spec as this allows the AS/OP to 
determine if the RS is "authorized" to introspect the token.

I know that Justin implemented a simple token exchange model that 
allowed for downstream chaining.

Another thing to consider is scope issues. Does the token the native app 
received have more scopes than the RS should be able to leverage? Is so, 
the native app should downscope the access token before sending it to 
the RS.

Thanks,
George

On 8/12/15 1:01 PM, Adam Lewis wrote:
> 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.
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 19 Aug 2015 11:37:29 +0900

It is not directly, but Sender Constrained JWT for OAuth 2.0
( https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05 )
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

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Mike Jones <[email-masked]>
Date: Wed, 19 Aug 2015 02:44:19 +0000

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-masked]] 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 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-masked]<mailto:[email-masked]>>:
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-masked]<mailto:[email-masked]>
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

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 19 Aug 2015 13:03:54 +0900

I have dug into it why it ended up like that. The approved text per the
ticket #712 and #830 was:

azp
   OPTIONAL. Authorized Presenters.
   This member identifies OAuth 2.0 Client(s) and potentially
   other parties authorized to use this ID Token as an assertion
   of the identity of the ID Token's subject at the ID Token's audiences.
   If present, it MUST contain the client_id or other identifiers for
   all Authorized Presenters.
   The issuer is not to be listed as an Authorized Presenter.
   This Claim is only needed when the party requesting the ID Token
   is not the same as the sole audience of the ID Token.
   It MAY be included even when the Authorized Presenter is the same
   as the sole audience.
   Authorized Presenter values should be verified by the participants,
   however the mechanisms for validating azp values are beyond the
scope of this specification.
   In the general case,  the azp value is an array of
   case sensitive strings, each containing a StringOrURI value.
   In the special case when the ID Token has one authorized presenter,
   the azp value MAY be a single  case sensitive string containing a
StringOrURI value.

It got changed to the one that Mike sited without any ticket. It is a
mystery.

Nat

2015-08-19 11:44 GMT+09:00 Mike Jones <[email-masked]>:

> 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-masked]] *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>
> )
>
> <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)
>
> <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
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 19 Aug 2015 04:59:28 +0000

The “azp” description was changed after the in-person OpenID Connect working group meeting at Google on 6-May-13, in which we agreed that “azp” would be used to represent the issued-to information, and that the claim would be named “Authorized Party”.  See the meeting notes at http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130506/003466.html, including attachment http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0005.jpg, which documents that we decided to represent issued-to information with “azp” and attachment http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0006.jpg, which documents that the “azp” claim is to represent an “Authorized Party”.  We also decided to make “azp” single-valued there, where it had previously been multi-valued.

Breno de Medeiros and Naveen Agarwal of Google were at the meeting, and in fact, were behind many of these changes, which is significant, since they were the inventors of this functionality.  They concurred with and participated developing these resolutions previously open issues about the meanings of “aud” and “azp”.  Afterwards, the meeting notes were sent to the working group mailing list for review there and no objections were raised.

There’s no mystery.

Furthermore, all of this text went through both the 45 day Implementer’s Draft 2 public review period announced at http://openid.net/2013/06/07/review-of-proposed-openid-connect-implementers-drafts/ and the 60 day Final Specification public review period announced at http://openid.net/2013/12/20/review-of-proposed-final-openid-connect-specifications-and-implementers-drafts/, and no objections were raised during those reviews either.  People seemed happy with the resolution arrived at during the working group meeting.

So in conclusion, it would probably be less confusing to all concerned if you were to stop referring to “azp” as “authorized presenter” or ascribing those semantics to it (whatever those may be).  Sometime before Implementer’s Draft 2 of OpenID Connect that terminology was used, but the working group changed that and the meaning of “azp” by consensus in May 2013 and it’s been that way ever since.  Trying to overload “azp” with a different meaning than what’s in the standard seems counterproductive, which is why I wrote my original note of clarification.

Thanks for taking this into account.

                                                            Best wishes,
                                                            -- Mike

From: Nat Sakimura [mailto:[email-masked]]
Sent: Tuesday, August 18, 2015 9:04 PM
To: Mike Jones
Cc: Adam Lewis; OAuth WG
Subject: Re: [OAUTH-WG] RS as a client guidance

I have dug into it why it ended up like that. The approved text per the ticket #712 and #830 was:

azp

   as the sole audience.

   however the mechanisms for validating azp values are beyond the scope of this specification.

   the azp value MAY be a single  case sensitive string containing a StringOrURI value.

It got changed to the one that Mike sited without any ticket. It is a mystery.

Nat

2015-08-19 11:44 GMT+09:00 Mike Jones <[email-masked]<mailto:[email-masked]>>:
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

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%7c718a77de87a54312a76b08d2a84b33cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rak35YM4lwq191Sbx0G9feviUU2ltCxhDS3auYuA6ew%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%7c718a77de87a54312a76b08d2a84b33cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rvGHkfj1Iie4BTStOyqzF6zfUESvID3JR3%2bkKQZel7w%3d>.

                                                            -- Mike

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] 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

Nat

tx
adam

--
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%7c718a77de87a54312a76b08d2a84b33cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=YF1hbON1WremXC%2blR0N43pDiBVr%2fjhBbAieEDtKkv1E%3d>
@_nat_en

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 19 Aug 2015 15:12:56 +0900

Sorry OAuth folks: I have mistakingly Cc: all'ed. This is OpenID Connect ID
Token stuff and not pertinent to OAuth WG per se nor this discussion which
was about the access token. I should have removed the list from Cc:.

I will respond more stuff directly related to the original thread
subsequently.

2015-08-19 13:59 GMT+09:00 Mike Jones <[email-masked]>:

> The “azp” description was changed after the in-person OpenID Connect
> working group meeting at Google on 6-May-13, in which we agreed that “azp”
> would be used to represent the issued-to information, and that the claim
> would be named “Authorized Party”.  See the meeting notes at
> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130506/003466.html,
> including attachment
> http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0005.jpg,
> which documents that we decided to represent issued-to information with
> “azp” and attachment
> http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130508/6d9b0ac0/attachment-0006.jpg,
> which documents that the “azp” claim is to represent an “Authorized
> Party”.  We also decided to make “azp” single-valued there, where it had
> previously been multi-valued.
>
>
>
> Breno de Medeiros and Naveen Agarwal of Google were at the meeting, and in
> fact, were behind many of these changes, which is significant, since they
> were the inventors of this functionality.  They concurred with and
> participated developing these resolutions previously open issues about the
> meanings of “aud” and “azp”.  Afterwards, the meeting notes were sent to
> the working group mailing list for review there and no objections were
> raised.
>
>
>
> There’s no mystery.
>
>
>
> Furthermore, all of this text went through both the 45 day Implementer’s
> Draft 2 public review period announced at
> http://openid.net/2013/06/07/review-of-proposed-openid-connect-implementers-drafts/
> and the 60 day Final Specification public review period announced at
> http://openid.net/2013/12/20/review-of-proposed-final-openid-connect-specifications-and-implementers-drafts/,
> and no objections were raised during those reviews either.  People seemed
> happy with the resolution arrived at during the working group meeting.
>
>
>
> So in conclusion, it would probably be less confusing to all concerned if
> you were to stop referring to “azp” as “authorized presenter” or ascribing
> those semantics to it (whatever those may be).  Sometime before
> Implementer’s Draft 2 of OpenID Connect that terminology was used, but the
> working group changed that and the meaning of “azp” by consensus in May
> 2013 and it’s been that way ever since.  Trying to overload “azp” with a
> different meaning than what’s in the standard seems counterproductive,
> which is why I wrote my original note of clarification.
>
>
>
> *From:* Nat Sakimura [mailto:[email-masked]]
> *Sent:* Tuesday, August 18, 2015 9:04 PM
> *To:* Mike Jones
> *Cc:* Adam Lewis; OAuth WG
>
> 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%7c718a77de87a54312a76b08d2a84b33cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rak35YM4lwq191Sbx0G9feviUU2ltCxhDS3auYuA6ew%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%7c718a77de87a54312a76b08d2a84b33cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rvGHkfj1Iie4BTStOyqzF6zfUESvID3JR3%2bkKQZel7w%3d>
> .
>
>
>
>                                                             -- Mike
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c718a77de87a54312a76b08d2a84b33cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=YF1hbON1WremXC%2blR0N43pDiBVr%2fjhBbAieEDtKkv1E%3d>
> @_nat_en
>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 19 Aug 2015 15:17:49 +0900

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

---

From: John Bradley <[email-masked]>
Date: Wed, 19 Aug 2015 15:05:00 -0300

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-masked]> 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-masked] <mailto:[email-masked]>>:
> 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-masked] <mailto:[email-masked]>] On Behalf Of Nat Sakimura
> ( 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> )
> 
> 2015-08-13 2:01 GMT+09:00 Adam Lewis <[email-masked] <mailto:[email-masked]>>:
> 
> Hi,
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> 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)
> 
> 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)
> http://nat.sakimura.org/ <http://nat.sakimura.org/>
> @_nat_en

---

From: Mike Jones <[email-masked]>
Date: Wed, 19 Aug 2015 18:37:41 +0000

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-masked]]
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

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-masked]<mailto:[email-masked]>> 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

azp

                                                            -- Mike

Nat

tx
adam

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 20 Aug 2015 09:29:59 +0900

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-masked]>さんは書きました:

> 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-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> *Sent:* Wednesday, August 19, 2015 11:05 AM
> *To:* Nat Sakimura
> *Cc:* Mike Jones; OAuth WG
> 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.
>
> 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-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>
>
> So, Mike,
>
>
>
> Authorized Presenter is a defined term in *Sender Constrained JWT for
> OAuth 2.0*
>
> 2015-08-19 11:44 GMT+09:00 Mike Jones <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>:
>
> *From:* OAuth [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On Behalf Of *Nat
> Sakimura
> 2015-08-13 2:01 GMT+09:00 Adam Lewis <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>:
>
> Hi,
>
>
>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: John Bradley <[email-masked]>
Date: Wed, 19 Aug 2015 21:35:22 -0300

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-masked]> 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-masked] <mailto:[email-masked]>>さんは書きました:
> 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-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>] 
> On Aug 19, 2015, at 3:17 AM, Nat Sakimura <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
> 
>  
> 
> So, Mike, 
> 
>  
> 
> 2015-08-19 11:44 GMT+09:00 Mike Jones <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>:
> 
> From: OAuth [mailto:[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>] On Behalf Of Nat Sakimura
> 2015-08-13 2:01 GMT+09:00 Adam Lewis <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>:
> 
> Hi,
> 
>  
> 
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>  
> 
> 
> 
> -- 
> Nat Sakimura (=nat)

---

From: Justin Richer <[email-masked]>
Date: Wed, 19 Aug 2015 20:39:59 -0400

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-masked] 
>> <mailto:[email-masked]>> 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-masked] 
>> <mailto:[email-masked]>> さんは書きました:
>>
>>     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-masked]
>>     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.
>>
>>     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.
>>
>>         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
>>
>>         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.
>>
>>         http://openid.net/specs/openid-connect-core-1_0.html in the
>>         IANA “JSON Web Token Claims” registry at
>>         *From:*OAuth [mailto:[email-masked]
>>         <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On
>>         Behalf Of *Nat Sakimura
>>         It is not directly, but *_Sender Constrained JWT for OAuth 2.0_*
>>
>>         (
>>         https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05
>>         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
>>
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 19 Aug 2015 21:49:55 -0300

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-masked]> 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 Aug 19, 2015, at 9:29 PM, Nat Sakimura < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 2015年8月20日木曜日、Mike Jones<[email-masked] <mailto:[email-masked]>> さんは書きました:
>>> 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 <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: <javascript:_e(%7B%7D,'cvml',[email-masked]');>[email-masked] <mailto:[email-masked]>] 
>>>  <https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05>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 < <javascript:_e(%7B%7D,'cvml',[email-masked]');>[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>  
>>> So, Mike, 
>>> 
>>>  
>>> (  <https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05>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 < <javascript:_e(%7B%7D,'cvml',[email-masked]');>[email-masked] <mailto:[email-masked]>>:
>>> 
>>> 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 athttp://www.iana.org/assignments/jwt/jwt.xhtml <http://www.iana.org/assignments/jwt/jwt.xhtml>.
>>> 
>>>  
>>>                                                             -- Mike
>>> 
>>>  
>>> From: OAuth [mailto: <javascript:_e(%7B%7D,'cvml',[email-masked]');>[email-masked] <mailto:[email-masked]>] On Behalf Of Nat Sakimura
>>> (  <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>https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05 <https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-05> )
>>> 
>>> 2015-08-13 2:01 GMT+09:00 Adam Lewis < <javascript:_e(%7B%7D,'cvml',[email-masked]');>[email-masked] <mailto:[email-masked]>>:
>>> 
>>> Hi,
>>> 
>>>  
>>>  <javascript:_e(%7B%7D,'cvml',[email-masked]');>[email-masked] <mailto:[email-masked]>
>>>  <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>https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> 
>>> 
>>>  
>>> --
>>> 
>>> Nat Sakimura (=nat)
>>> 
>>>  <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>http://nat.sakimura.org/ <http://nat.sakimura.org/>
>>> @_nat_en
>>> 
>>> 
>>> 
>>>  
>>> --
>>> 
>>> Nat Sakimura (=nat)
>>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Aug 2015 00:52:28 +0000

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-masked]] 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

John B.

On Aug 19, 2015, at 9:39 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

John B.
On Aug 19, 2015, at 9:29 PM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

2015年8月20日木曜日、Mike Jones<[email-masked]<mailto:[email-masked]>> さんは書きました:
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-masked]<mailto:[email-masked]>]
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

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.

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

azp

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

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.

Nat

tx
adam

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
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

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>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 20 Aug 2015 10:01:25 +0900

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-masked]>:

> 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-masked]] *On Behalf Of *John Bradley
> *Sent:* Wednesday, August 19, 2015 5:50 PM
> *To:* Justin Richer
>
> *Cc:* OAuth WG
> 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.
>
>
>
> 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
>
> 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.
>
> 2015年8月20日木曜日、Mike Jones<[email-masked]> さんは書きました:
>
> 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
> <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-masked]]
> <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
> <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
>
>
>
> <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>
> <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
>
>
>
> <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>
> )
>
> <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)
>
> <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)
>
> <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
>
> <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)
>
> <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
>
>
>
>
>
>
>
>
> 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>
>
>
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 19 Aug 2015 21:29:36 -0400

I read it that way as well.
  -- Justin

On 8/19/2015 9:01 PM, Nat Sakimura wrote:
> 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.
>
> 2015-08-20 9:52 GMT+09:00 Mike Jones <[email-masked] 
> <mailto:[email-masked]>>:
>
>     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.
>
>     <mailto:[email-masked]>] *On Behalf Of *John Bradley
>     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.
>
>         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
>
>             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-masked] <mailto:[email-masked]>> 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
>                 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
>                 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
>
>                 <mailto:[email-masked]>]
>                 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
>                     On Aug 19, 2015, at 3:17 AM, Nat Sakimura
>                     <[email-masked] <mailto:[email-masked]>>
>                     wrote:
>
>                     So, Mike,
>
>                     It is used in the context of OAuth 2.0 Access
>                     Token, not a claim in ID Token of OpenID Connect.
>
>                     Nat
>
>                     <mailto:[email-masked]>>:
>
>                     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.
>
>                     <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
>
>                     <mailto:[email-masked]>] *On Behalf Of
>                     *Nat Sakimura
>                     To be used, the "client" has to present a proof
>                     that it is indeed the party pointed by "azp".
>
>                     <mailto:[email-masked]>>:
>
>                     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'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
>
>

---

From: "Kepeng Li" <[email-masked]>
Date: Thu, 20 Aug 2015 09:56:00 +0800

> From what I see, authorized presenter is a subset of authorized party.

That is also my understanding.

Kind Regards
Kepeng

发件人:  Nat Sakimura <[email-masked]>
日期:  Thursday, 20 August, 2015 9:01 am
至:  Mike Jones <[email-masked]>
抄送:  OAuth WG <[email-masked]>
主题:  Re: [OAUTH-WG] RS as a client guidance

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.

2015-08-20 9:52 GMT+09:00 Mike Jones <[email-masked]>:
> 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.
> 
>  
>> 
>> 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
>> 
>>>> Let me second John’s point that we shouldn’t have two different definitions
>>>> for “azp”.  As I wrote in my friendly review of
>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.o
>>>> rg%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg14679.html&data=01%7c01%7cMi
>>>> chael.Jones%40microsoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86
>>>> f141af91ab2d7cd011db47%7c1&sdata=3TbSJzfONy8nvH1hDcjGQPmdeen39IJDHk1R99tD7B
>>>> E%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.o
>>>> rg%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
>>>> 
>>>>  
>>>> 
>>>> Having two azp claims with slightly different definitions is not a good way
>>>> to go,  both access tokens and id_tokens are JWT.
>>>> 
>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ie
>>>>> tf.org%2fhtml%2fdraft-sakimura-oauth-rjwtprof-05&data=01%7c01%7cMichael.Jo
>>>>> nes%40microsoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af9
>>>>> 1ab2d7cd011db47%7c1&sdata=VTIpHaqCd%2fmxrEfxKD8i5h5AzeWV5rsZC05oVOv73SA%3d
>>>>> >  should probably be using a different claim to reduce the confusion.
>>>> 
>>>>  
>>>> John B.
>>>> 
>>>>  
>>>> 
>>>>  
>>>>> 
>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ie
>>>>> tf.org%2fhtml%2fdraft-sakimura-oauth-rjwtprof-05&data=01%7c01%7cMichael.Jo
>>>>> nes%40microsoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af9
>>>>> 1ab2d7cd011db47%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
>>>>> 
>>>>>  
>>>>> 
>>>>> 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.
>>>>> 
>>>>>  
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.ne
>>>>> t%2fspecs%2fopenid-connect-core-1_0.html&data=01%7c01%7cMichael.Jones%40mi
>>>>> crosoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd
>>>>> 011db47%7c1&sdata=3e6US9sxQoQVejthrxO%2fo%2bvdltE%2fBUj1NUSMBk6vOS0%3d>
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.iana.
>>>>> org%2fassignments%2fjwt%2fjwt.xhtml&data=01%7c01%7cMichael.Jones%40microso
>>>>> ft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db
>>>>> 47%7c1&sdata=kijVXFcn2du2Ha5xvX%2bTgwohVGOl%2fxmryplQNsWHYzo%3d> .
>>>>> 
>>>>>  
>>>>>                                                             -- Mike
>>>>> 
>>>>>  
>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ie
>>>>> tf.org%2fhtml%2fdraft-sakimura-oauth-rjwtprof-05&data=01%7c01%7cMichael.Jo
>>>>> nes%40microsoft.com%7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af9
>>>>> 1ab2d7cd011db47%7c1&sdata=VTIpHaqCd%2fmxrEfxKD8i5h5AzeWV5rsZC05oVOv73SA%3d
>>>>> >  )
>>>>> 
>>>>> <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)
>>>>> 
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakim
>>>>> ura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8fc7f0da91324dd9
>>>>> 570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HNVIwuDJAOWx
>>>>> fWyduzov8RK%2fZKG17xQnYZVFWv94oqY%3d>
>>>>> @_nat_en
>>>>> 
>>>>> 
>>>>>  
>>>>> -- 
>>>>> 
>>>>> Nat Sakimura (=nat)
>>>>> 
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakim
>>>>> ura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8fc7f0da91324dd9
>>>>> 570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HNVIwuDJAOWx
>>>>> fWyduzov8RK%2fZKG17xQnYZVFWv94oqY%3d>
>>>>> @_nat_en
>>>>> <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)
>>>> 
>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimu
>>>> ra.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8fc7f0da91324dd957
>>>> 0908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HNVIwuDJAOWxfWy
>>>> duzov8RK%2fZKG17xQnYZVFWv94oqY%3d>
>>>> @_nat_en
>>>>  
>>>  
>>> 
>>> 
>>> 
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.o
>>> rg%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com
>>> %7c8fc7f0da91324dd9570908d2a8f94fc1%7c72f988bf86f141af91ab2d7cd011db47%7c1&s
>>> data=LjPpTGV4iGtx1SQKfz%2bsYv3ZdxEqyoTXrCd1BCqvMlw%3d>
>>  
>  
> 

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________ OAuth mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/oauth