[OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-10.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : JSON Web Token (JWT) Profile for OAuth 2.0 Access 
Tokens
Author  : Vittorio Bertocci
Filename: draft-ietf-oauth-access-token-jwt-10.txt
Pages   : 20
Date: 2020-09-23

Abstract:
   This specification defines a profile for issuing OAuth 2.0 access
   tokens in JSON web token (JWT) format.  Authorization servers and
   resource servers from different vendors can leverage this profile to
   issue and consume access tokens in interoperable manner.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question

[Vittorio Bertocci]

Thanks Brian, Logan.
On clarity. I tweaked that section and produced a new draft (-10).
Details:

  *   Formally, the fact that we are referring to the User entity should be 
unambiguous. 4.1.2 is a subsection of 4.1, which is titled "User Resource 
Schema”.
However as a frequent critic of the excessive cyclomatic complexity of the 
specs, I am making myself guilty of precisely the same sin 😊 your suggestion 
can save the reader the need to follow and parse the reference to understand 
the situation, hence it’s a good improvement to clarity.
  *   For what concerns the actual format of the claims. The groups entity 
actually appears as non-normative example in 
https://tools.ietf.org/html/rfc7643#section-8.2; I can make an explicit 
reference to that and make things a bit more discoverable.
  *   For roles and entitlements, things are murkier.
Before embarking in this endeavor I too had the expectation that this would be 
a flat list of strings, but digging a bit in existing implementations it turns 
out that’s not necessarily the case. For example, Slack SCIM represents 
individual roles as two possible forms { “value”:, “primary”; }|  { 
“value”:}, whereas databricks uses { “value”:}; WSO2 uses { 
“value”:, “type”; }.
So for those two I don’t think we can do better than the current statement 
about SCIM not supplying a vocabulary for them.
  *   I had some issues w the references where the section links were turned 
into local links, as it happened in the past. That should be fixed too.
  *   I applied the “” notation to the attributes, given that we are turning 
them into claims it seems clearer to sue the same typographic concention.



  *   side note… 
Excellent point, fixed.


From: Logan Widick 
Date: Monday, September 21, 2020 at 19:09
To: Brian Campbell 
Cc: Vittorio Bertocci , "oauth@ietf.org" 

Subject: Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question

If I understand "The intent would be to present that information in the same 
way you would when querying a users/, encoded in claims" correctly, the 
"roles", "groups", and "entitlements" claims are the same types as the "roles", 
"groups", and "entitlements" attributes of the User resource schema (pages 
24-25 of RFC 7643 for the text; pages 63-67 of RFC 7643 for the schema)? In the 
schema the attributes are all "complex" (object) type and "multivalued" (array 
of), although the text for some of these attributes has some "No vocabulary or 
syntax..." remarks.

If that understanding is correct, it might be a good idea to replace the 
references to "RFC 7643", "Section 4.1.2 of RFC 7643", and "RFC 7643, Section 
4.1.2" with something more specific like "the  attribute(s) of the User 
resource schema from Section 4.1.2 of RFC 7643".

On Mon, Sep 21, 2020, 15:33 Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
At some point I'm going to be among the lucky few who will be asked to review 
the JWT claims registration request. One of the criteria to consider is 
"whether the registration description is clear" and Logan's questions suggest 
that perhaps the descriptions of these claims are not sufficiently clear. My 
assumption was that the claim value for "roles", "groups" and "entitlements" 
was going to be an array of strings. Trying to validate my assumption, I went 
looking at the text in 
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-2.2.3.1
 and 
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-7.2 
and followed the reference to https://tools.ietf.org/html/rfc7643#section-4.1.2 
and, honestly, it wasn't particularly clear to me. Maybe it's my lack of 
familiarity with the details of SCIM and the language of RFC 7643. But I think 
that, for the sake of clarity and interoperability, some additional specificity 
is needed.

Side note: the "Section 2.2.2.1 of [[this specification]]" references in 
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-7.2.1 
are problmatic (there is no such section in this document) and probably should 
be to 2.2.3.1.

On Fri, Sep 18, 2020 at 6:28 PM Vittorio Bertocci 
mailto:40auth0@dmarc.ietf.org>>
 wrote:
Hi Logan,
Thanks for the note.
The intent would be to present that information in the same way you would when 
querying a users/, encoded in claims; hence groups would be a list of 
values representing  what groups the subject belongs to, rather than a list of 
full group definitions (with all the other members belonging to them, for 
example) which would go beyond the intended use of the information (supplying 
authorization information about the subject).
I tried to keep the language high level as I didn’t want to duplicate SCIM 
guidance, or inadvertently narrow down the options products have to implement 
this.  If you think this is too vague, we can try to be more specific.

From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of Logan Widick mailto:logan.wid...@gmail.com>>
Date: Wednesday, September 16, 20

Re: [OAUTH-WG] New podcast on identity specifications

[Denis]

Hello Brian and Vittorio,

I have two observations:

 * draft-fett-oauth-dpop-04 which is the last version expired on 5
   September 2020,
 * the podcast as well as draft-fett-oauth-dpop-04 omit to mention the
   client/user collaborative attack against which
   draft-fett-oauth-dpop-04 is ineffective.


Denis

PS. The podcast is a nice effort but is far too long (29:37).


The mTLS vs DPoP was good in articulating how the two specs are alike, 
how they differ and which particular type of app they are meant to serve.


I'm saying this as a person who is generally allergic to technical 
podcasts :)


Maybe every RFC that comes out of this WG should have a podcast link 
at the top, where the authors discuss it in simple, honest and 
non-speccy terms, because that's often how people are best able to 
perceive the spirit and subtleties of some technical or spec work.


Vladimir

On 21/09/2020 09:40, Vittorio Bertocci wrote:


Dear all,

This is an informal mail to inform you that there’s a new podcast 
, identityunlocked.com 
, dedicated to inform and explain new 
identity specs developments for developers.


You can find a more detailed explanation of the podcast’s goals in 
https://auth0.com/blog/identity-unlocked-a-podcast-for-developers/, 
but the TL;DR is that the spec themselves aren’t all that easy to 
read for the non-initiated, and a lot of useful info emerges during 
the discussions leading to the spec but rarely surface in a usable 
form to the people who don’t participate in discussions.


The first episode 
, 
featuring Brian Campbell discussing MTLS & DPoP, should give you an 
idea of what season 1 of the show will look like.


The full list of the first run is available here 
. 
Of 6 episodes, 3 of them are about specifications coming out of this 
WG- and all guests are actively involved in the IETF.


My main goals sharing this info here are

  * *Letting you know that the podcast exists*, so that you can make
use of it if you so choose (e.g. referring people to it if they
need to better understand something covered in an episode)
  * *Soliciting proposals for new episodes*: topics you believe are
currently underserved, topics you are often asked about, topics
you would like to be interviewed about on the show
  * *Growing the show’s subscriber base*. I was able to get backing
from my company to produce a podcast that has exactly ZERO
product pitches and is purely about identity specs promotion, on
the gamble that the topic does have an audience finding it
useful. So far the reception has been great, and we need to keep
it up if we want to have a season 2.

I hope you’ll find the initiative useful!

Cheers,

V.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] About draft-ietf-oauth-access-token-jwt-10

[Denis]

Hello Vittorio,

I have three comments numbered 1, 2 and 3.

*Comment 1:**
*

Section 3 states:

   3.  Requesting a JWT Access Token

   An authorization server can issue a JWT access token in response
   to any authorization grant defined by [RFC6749] and subsequent
   extensions meant to result in an access token.

   If the request includes a "resource" parameter (as defined in
   [RFC8707]), the resulting JWT access token "aud" claim SHOULD have
   the same value as the "resource" parameter in the request.

I had a discussion I had on the mailing list with Hannes on September 10:

   [Denis] I believe, it would be worthwhile to add a sentence, just
   after this sentence, with the following text:

 When an authorization server decides to issue a JWT access token
   compliant to this profile, then the following requirements apply.
   (...)

   [Hannes] That’s fine for me because this is what the intended effect
   of the spec is.

This portion of text from section 3 should be changed into:

   3.  Requesting a JWT Access Token

   An authorization server can issue a JWT access token in response
   to    any authorization grant defined by [RFC6749] and subsequent
   extensions meant to result in an access token.

   *When an authorization server decides to issue a JWT access token
   compliant to this profile, then the following requirements apply. *

   If the request includes a "resource" parameter (as defined in
   [RFC8707]), the resulting JWT access token "aud" claim SHOULD have
   the same value as the "resource" parameter in the request.

*Comment 2:**
*

Section 6 states:

6.  Privacy Considerations

   As JWT access tokens carry information by value, it now becomes
   possible for clients and potentially even end users to directly peek
   inside the token claims collection.

   The client *MUST NOT* inspect the content of the access token:
   the authorization server and the resource server might decide to change
   token format at any time (for example by switching from this
   profile to opaque tokens) hence any logic in the client relying on the
   ability to read the access token content would break without
   recourse.

RFC 2119 defines the meaning of MUST NOT or SHOULD NOT:

   2. *MUST NOT*   This phrase, or the phrase "SHALL NOT", mean that
   the definition is an absolute prohibition of the specification.

   (...)

   4. *SHOULD NOT*   This phrase, or the phrase "NOT RECOMMENDED" mean
   that  there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full 
   implications should be understood and the case carefully weighed 
   before implementing
   any behavior described with this label.

The first sentence of section 6 recognizes that it is technically 
possible for clients and potentially even end users to directly peek 
inside the token claims collection.
There may exist valid reasons in particular circumstances when the 
particular behavior is acceptable or even useful, but there is no 
assurance that this can be done
since the authorization server and the resource server might decide to 
change the token format at any time.


The sentence :

   The client *MUST NOT* inspect the content of the access token:

should be changed into:

   The client *SHOULD **NOT* inspect the content of the access token:

*Comment 3:**
*

Section 6 also state:

  This profile mandates the presence of the "sub" claim in every JWT 
access token, making it possible for resource servers to rely on that
   information for correlating incoming requests with data stored 
locally for the authenticated principal.  Although the ability to
   correlate requests might be required by design in many scenarios, 
there are scenarios where the authorization server might want to
   prevent correlation.  The "sub" claim should be populated by the 
authorization servers according to a privacy impact assessment.  For
   instance, if a solution requires preventing tracking principal 
activities across multiple resource servers, the authorization server
   should ensure that JWT access tokens meant for different resource 
servers have distinct "sub" values that cannot be correlated in the
   event of resource servers collusion.  Similarly, if a solution 
requires preventing a resource server from correlating the
   principal’s activity within the resource itself, the authorization 
server should assign different "sub" values for every JWT access
   token issued.  In turn, the client should obtain a new JWT access 
token for every call to the resource server, to ensure that the
   resource server receives different "sub" and "jti" values at every 
call, thus preventing correlation between distinct requests.


As already mentioned on this mailing list, the above sentences would 
modify the semantics of the "sub" claim.


 While reading RFC 7519, no reader may be able to figure out th

Re: [OAUTH-WG] [JAR] scope parameter outside request object of OIDC request

[Takahiko Kawasaki]

Hi Vladimir,

Thank you for your reply. It sounds that your opinion is "`scope` request
parameter must exist outside the request object even if JAR applies if the
authorization request is an OIDC request". I'm on the fence on this topic
and just wondered whether those who had wanted to remove `response_type`
outside the request object (although doing it was a breaking change) would
want to remove `scope` outside the request object too with the same
motivation (although I don't remember well what was the motivation). JAR
dares to drop `response_type`, so it would not be surprising to see that
JAR dares to drop `scope` (including `openid`) too.

OIDC Core 1.0 requires `response_type`, but JAR allows omission of the
parameter if the parameter is included in the request object.

If we applied the same logic, we would be able to state:

OIDC Core 1.0 requires `scope` (including `openid`), but JAR allows
omission of the parameter if the parameter is included in the request
object.

In terms of `response_type`, practically speaking, JAR has modified OIDC
Core 1.0. Because JAR has already been allowed to go so far as that point,
I would say it is difficult to find a convincing reason not to allow
omission of `scope`.

AFAIK, in the context of OIDC Core 1.0, parameters that are required to
exist outside a request object even if they are included in the request
object are `client_id`, `response_type` and `scope`. Because `client_id` is
mandatory in JAR (it has become mandatory after long discussion),
discussion for the parameter is not needed. Because the community has
already reached consensus that `response_type` can be omitted, discussion
for the parameter is not needed, either. What I've brought here is
discussion for `scope`, hopefully the last parameter that is affected by
JAR.

Again, I'm on the fence on this topic. However, because logical conclusion
(at least of mine) is that JAR should allow omission of `scope` (it also
should be noted that JAR's basic rule prohibits referring to request
parameters outside a request object), I want to see explicit consensus if
`scope` (including `openid`) outside a request object is still required
even after JAR is enabled.

In short, my question is "Should `scope` be omitted?" I guess that the
conclusion will affect the official conformance suite.

Best Regards,
Takahiko Kawasaki
Authlete, Inc.



On Tue, Sep 22, 2020 at 5:59 AM Vladimir Dzhuvinov 
wrote:

> Hi Taka,
> On 21/09/2020 20:12, Takahiko Kawasaki wrote:
>
> If we allow JAR (JWT Secured Authorization Request) to relax the
> requirement of `response_type` request parameter (outside a request object)
> from mandatory to optional, should we relax the following requirement of
> `scope` request parameter stated in OIDC Core 1.0 Section 6.1, too?
>
> --
> Even if a scope parameter is present in the Request Object value, a scope
> parameter MUST always be passed using the OAuth 2.0 request syntax
> containing the openid scope value to indicate to the underlying OAuth 2.0
> logic that this is an OpenID Connect request.
> --
>
> Otherwise, an authorization request like "client_id=...&request(_uri)=..."
> fails if the request object represents an OIDC request. An authorization
> request has to look like "client_id=...&request(_uri)=...&scope=openid"
> (`scope` including `openid` has to be given) even if the authorization
> server conforms to JAR and allows omission of `response_type` request
> parameter.
>
> The bottom of section 5 has normative text which allows a JAR compliant
> server to also comply with the OIDC spec with its own style of request /
> request_uri parameter handling insofar as to not reject other query params
> (such as scope, etc). The difference is that according to JAR their values
> cannot be used or merged (as in OIDC). But what can be reasonably done is
> to detect scope=openid as you say and then switch to OIDC style request
> object behavior.
>
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30#section-5
>
>The client MAY send the parameters included in the request object
>duplicated in the query parameters as well for the backward
>compatibility etc.  However, the authorization server supporting this
>specification MUST only use the parameters included in the request
>object.
>
> The confusion between the two specs clears when it's seen that the request
> objects in OIDC and JAR have different objectives.
>
> In OIDC the objective is to enable securing of selected parameters.
>
> In JAR the objective is to secure the entire authz request.
>
>
>
> I think that implementers want to know consensus on this because it
> affects implementations. Has this been discussed yet?
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
>
> Vladimir
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
ht

Re: [OAUTH-WG] [JAR] scope parameter outside request object of OIDC request

[Justin Richer]

In my opinion, all parameters should be able to be passed inside the request 
object, including `scope`. 

We couldn’t do that kind of thing in OIDC because that would be a breaking 
change to existing requirements in OAuth 2. JAR is taking the step of 
overriding those requirements, and so it should do so with all parameters.

There are a lot of things in OIDC that are a little wonky like this, where the 
general solution turned out to be slightly different than the tightly fit 
solution that OIDC pioneered. Discovery and issuer URLs are another notable 
example beyond this one.

In my view, OIDC should be updated to redefine its behavior in light of the 
family of new general purpose protocol extensions, including JAR. This could 
probably be done in a way that an IdP could support both the “classic” way of 
doing request objects as well as the “new” way, but likely for different 
clients. In which case, I think the behavior switch would be similar to what 
Vladimir describes.

 — Justin

> On Sep 23, 2020, at 7:58 AM, Takahiko Kawasaki  wrote:
> 
> Hi Vladimir,
> 
> Thank you for your reply. It sounds that your opinion is "`scope` request 
> parameter must exist outside the request object even if JAR applies if the 
> authorization request is an OIDC request". I'm on the fence on this topic and 
> just wondered whether those who had wanted to remove `response_type` outside 
> the request object (although doing it was a breaking change) would want to 
> remove `scope` outside the request object too with the same motivation 
> (although I don't remember well what was the motivation). JAR dares to drop 
> `response_type`, so it would not be surprising to see that JAR dares to drop 
> `scope` (including `openid`) too.
> 
> OIDC Core 1.0 requires `response_type`, but JAR allows omission of the 
> parameter if the parameter is included in the request object.
> 
> If we applied the same logic, we would be able to state:
> 
> OIDC Core 1.0 requires `scope` (including `openid`), but JAR allows omission 
> of the parameter if the parameter is included in the request object.
> 
> In terms of `response_type`, practically speaking, JAR has modified OIDC Core 
> 1.0. Because JAR has already been allowed to go so far as that point, I would 
> say it is difficult to find a convincing reason not to allow omission of 
> `scope`.
> 
> AFAIK, in the context of OIDC Core 1.0, parameters that are required to exist 
> outside a request object even if they are included in the request object are 
> `client_id`, `response_type` and `scope`. Because `client_id` is mandatory in 
> JAR (it has become mandatory after long discussion), discussion for the 
> parameter is not needed. Because the community has already reached consensus 
> that `response_type` can be omitted, discussion for the parameter is not 
> needed, either. What I've brought here is discussion for `scope`, hopefully 
> the last parameter that is affected by JAR.
> 
> Again, I'm on the fence on this topic. However, because logical conclusion 
> (at least of mine) is that JAR should allow omission of `scope` (it also 
> should be noted that JAR's basic rule prohibits referring to request 
> parameters outside a request object), I want to see explicit consensus if 
> `scope` (including `openid`) outside a request object is still required even 
> after JAR is enabled.
> 
> In short, my question is "Should `scope` be omitted?" I guess that the 
> conclusion will affect the official conformance suite.
> 
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
> 
> 
> 
> On Tue, Sep 22, 2020 at 5:59 AM Vladimir Dzhuvinov  > wrote:
> Hi Taka,
> 
> On 21/09/2020 20:12, Takahiko Kawasaki wrote:
>> If we allow JAR (JWT Secured Authorization Request) to relax the requirement 
>> of `response_type` request parameter (outside a request object) from 
>> mandatory to optional, should we relax the following requirement of `scope` 
>> request parameter stated in OIDC Core 1.0 Section 6.1, too?
>> 
>> --
>> Even if a scope parameter is present in the Request Object value, a scope 
>> parameter MUST always be passed using the OAuth 2.0 request syntax 
>> containing the openid scope value to indicate to the underlying OAuth 2.0 
>> logic that this is an OpenID Connect request.
>> --
>> 
>> Otherwise, an authorization request like "client_id=...&request(_uri)=..." 
>> fails if the request object represents an OIDC request. An authorization 
>> request has to look like "client_id=...&request(_uri)=...&scope=openid" 
>> (`scope` including `openid` has to be given) even if the authorization 
>> server conforms to JAR and allows omission of `response_type` request 
>> parameter.
> The bottom of section 5 has normative text which allows a JAR compliant 
> server to also comply with the OIDC spec with its own style of request / 
> request_uri parameter handling insofar as to not reject other query params 
> (such as scope, etc). The difference is t

Re: [OAUTH-WG] New podcast on identity specifications

[Brian Campbell]

Hello Denis,

The most recent version of the DPoP draft is not draft-fett-oauth-dpop-04
but rather draft-ietf-oauth-dpop-01, which doesn't expire until November. I
realize that the naming and versioning conventions of IETF documents are a
bit esoteric and can lend themselves to such mistakes. But someone who
insists on making unhelpful criticism of said documents should probably be
more mindful of such details.

This WG (and it's not the only WG where this has happened) has repeatedly
confirmed the rough consensus that these so-called collaboration attacks
are not something that DPoP, or any of the other documents you've said the
same about, is expected to address. Nor that there is even reason enough to
think that readers need to be told so. Your personal enthusiasm for the
topic does not change that and doesn't change the fundamental nature of how
OAuth works.

I am sorry to hear that you felt the podcast was too long. I can certainly
empathize with feeling like one's time has been wasted.




On Wed, Sep 23, 2020 at 3:38 AM Denis  wrote:

> Hello Brian and Vittorio,
> I have two observations:
>
>- draft-fett-oauth-dpop-04 which is the last version expired on 5
>September 2020,
>- the podcast as well as draft-fett-oauth-dpop-04 omit to mention the
>client/user collaborative attack against which draft-fett-oauth-dpop-04 is
>ineffective.
>
>
> Denis
>
> PS. The podcast is a nice effort but is far too long (29:37).
>
> The mTLS vs DPoP was good in articulating how the two specs are alike, how
> they differ and which particular type of app they are meant to serve.
>
> I'm saying this as a person who is generally allergic to technical
> podcasts :)
>
> Maybe every RFC that comes out of this WG should have a podcast link at
> the top, where the authors discuss it in simple, honest and non-speccy
> terms, because that's often how people are best able to perceive the spirit
> and subtleties of some technical or spec work.
>
> Vladimir
> On 21/09/2020 09:40, Vittorio Bertocci wrote:
>
> Dear all,
>
> This is an informal mail to inform you that there’s a new podcast
> , identityunlocked.com, dedicated to inform
> and explain new identity specs developments for developers.
>
> You can find a more detailed explanation of the podcast’s goals in
> https://auth0.com/blog/identity-unlocked-a-podcast-for-developers/, but
> the TL;DR is that the spec themselves aren’t all that easy to read for the
> non-initiated, and a lot of useful info emerges during the discussions
> leading to the spec but rarely surface in a usable form to the people who
> don’t participate in discussions.
>
> The first episode
> ,
> featuring Brian Campbell discussing MTLS & DPoP, should give you an idea of
> what season 1 of the show will look like.
>
> The full list of the first run is available here
> .
> Of 6 episodes, 3 of them are about specifications coming out of this WG-
> and all guests are actively involved in the IETF.
>
> My main goals sharing this info here are
>
>- *Letting you know that the podcast exists*, so that you can make use
>of it if you so choose (e.g. referring people to it if they need to better
>understand something covered in an episode)
>- *Soliciting proposals for new episodes*: topics you believe are
>currently underserved, topics you are often asked about, topics you would
>like to be interviewed about on the show
>- *Growing the show’s subscriber base*. I was able to get backing from
>my company to produce a podcast that has exactly ZERO product pitches and
>is purely about identity specs promotion, on the gamble that the topic does
>have an audience finding it useful. So far the reception has been great,
>and we need to keep it up if we want to have a season 2.
>
>
>
> I hope you’ll find the initiative useful!
>
> Cheers,
>
> V.
>
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth