Re: [OAUTH-WG] Transaction Authorization with OAuth

[Steinar Noem]

I do not have the depth of understanding of OAuth as you guys, so forgive
me if I'm missing the discussion completely.

For me this sort of boils down to how we establish trust between the
different roles in OAuth. For an API the trust lies between the AS and
itself. The API may have no trust in the clients directly, but relies on
the AS to provide the user consent, client authentication but also e.g. the
use of request objects. At least in my domain, the API might not trust
"claims" as parameters in a request from the client, but will trust the
"claims" in an access token.
In my domain the trust established between the client and the AS is an
important part of the ability to interact across security domains. It also
provides a way for us to establish domain standards for representing
different types of authoritative information.
For instance, we have a legal requirement to log certain types of
information about the user when exchanging sensitive information. This
information is usually tied to a OAuth scope, e.g. "get patient records".
The suggested use of "structured_scope" not only gives us an opportunity to
convey contextual information that can be shown in the user consent,  it
also gives us a way of enforcing national domain-specific standards of
expressing different types of information tied to the scope (e.g.
prescription, sick note, patient records etc) which would make
interoperability within the health sector easier.
Also, the health sector in Norway has a strict legislation regarding
privacy and patient rights,, so we would actually log the issued access
tokens with structured_scopes to fulfil some of the legal requirements.

Personally I'm not sure what makes more sense, the "structured_scope" or
"transaction_scope" name - but "transaction_scope" is more semantically
loaded.
I also agree with mr. Campbell that the concepts should be treated
separately.

Steinar


fre. 26. apr. 2019 kl. 19:58 skrev Brian Campbell :

> One thing that I think is missing from the article in the discussion of
> pros and cons is that in many cases a large or even voluminous request can
> be sent via auto submitting form post (like
> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html but
> the other way around from client to AS with the auth request), which
> doesn't then run into the same URI size problem.
>
> From a prospective standardization standpoint, there are really two
> distinct concepts in the article. One is the "Pushed Request Object" and
> the other the "Structured Scope". They are certainly complementary things
> but each could also be useful and used independently of one another. So I'd
> argue that they should be developed independently too.
>
>
>
> On Sat, Apr 20, 2019 at 12:21 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Hi all,
>>
>> I just published an article about the subject at:
>> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>> 
>>
>>
>> I look forward to getting your feedback.
>>
>> kind regards,
>> Torsten.
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *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
>


-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| stei...@udelt.no | h...@udelt.no  | +47 955 21 620 | www.udelt.no |
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization with OAuth

[Brian Campbell]

One thing that I think is missing from the article in the discussion of
pros and cons is that in many cases a large or even voluminous request can
be sent via auto submitting form post (like
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html but the
other way around from client to AS with the auth request), which doesn't
then run into the same URI size problem.

>From a prospective standardization standpoint, there are really two
distinct concepts in the article. One is the "Pushed Request Object" and
the other the "Structured Scope". They are certainly complementary things
but each could also be useful and used independently of one another. So I'd
argue that they should be developed independently too.



On Sat, Apr 20, 2019 at 12:21 PM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> Hi all,
>
> I just published an article about the subject at:
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>
>
> I look forward to getting your feedback.
>
> kind regards,
> Torsten.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_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

Re: [OAUTH-WG] Transaction Authorization with OAuth (Torsten Lodderstedt)

[George Fletcher]

I agree that we definitely need better definition and guidance around 
scopes and authorized access patterns.


I think what is unique about what Torsten is proposing is that in his 
case he wants to authorize an individual transaction (not a set of 
transactions). Normally, with scopes and access tokens the goal is to 
get an access token that can perform a number of transactions with a 
restricted set of capabilities.


I think we need to separate the concept of transactional authorization 
from capability authorization.


On 4/26/19 10:06 AM, Pedro Igor Silva wrote:

Hi Jaap,

Very good points. I have the same opinion about what you said about 
the meaning of scopes (and how people are actually using them), the 
resource-scope relationship and the importance of a standardized way 
of doing this form of authorization to address different use cases, 
not only delegation. Like George said in one of his messages, both 1st 
and 3rd party use cases could be considered by a solution like that.


I would love to see something based on OAuth like this:

#1) Client tries to access a protected resource. At this point, the 
client does not yet have a bearer token or the bearer token is lacking 
the required scopes/permissions. The resource server responds with:


/HTTP/1.1 403 Unauthorized /
/WWW-Authenticate: Bearer realm="example", error="invalid_token", 
*claim_token*="accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC"/


The claim_token response parameter returned by the resource server 
represents all the security constraints (e.g.: scopes) and information 
(e.g.: contextual) that the client needs in order to obtain a valid 
access token from the AS. This token can be built by the RS or even 
use some endpoint at the AS, as UMA does. It can be just a reference 
token too.


#2) Client obtains an access token from the token endpoint at the AS:

/POST /as/token.oauth2 HTTP/1.1/
/Host: as.example.com /
/Content-Type: application/x-www-form-urlencoded/
/grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Apermission/
/=https%3A%2F%2Fbackend.example.com 
%2Fapi%20/

/&*claim_token*=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC/
/_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC/
/_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token/

The example above shows a client request to the token endpoint when 
the client already has an access token and wants a new token with 
permissions to access a resource.


#3) Just like any other OAuth grant type, the token endpoint responds 
to the client as follows (success):


/HTTP/1.1 200 OK/
/Content-Type: application/json;charset=UTF-8/
/Cache-Control: no-store/
/Pragma: no-cache/
/
/
/{/
/"access_token":"2YotnFZFEjr1zCsicMWpAA"/
/"token_type":"example",/
/"expires_in":3600,/
/"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"/
/} /
/
/
#4) Clients can now access protected resources using the access token 
with all permissions granted by the server


It is not coincidence the similarities with and the usage of 
specs/drafts like token exchange, resource-indicator, UMA, Lodging 
Intent Pattern,??or even ACE's "AS Request Creation Hints" message. The 
point I would like to make is that we could leverage the 
standards/specs that exist today to address the problem without 
reinventing the wheel.


There are very interesting things in UMA specs that can be used here 
too, such as the possibility to perform incremental authorization or 
token upgrade, etc.


Regards.
Pedro Igor

On Thu, Apr 25, 2019 at 4:27 AM Jaap Francke 
> wrote:


Hi Torsten and others,

I just read your blog - having ???we need to re-think OAuth scopes???
in the title immediately drew my attention.
I find this interesting since I???m struggling with the concept of
scopes from time-to-time.
I???ll have to read the blog a few times more to get a good
understanding, but I would like to share some of my thoughts on
scopes.

I believe the OAuth scope concept has it???s limitations not only
for transactions but also for the more traditional ???resource??? concept.
RFC 6749 defines scopes as follows:
"The value of the scope parameter is expressed as a list of space-
 delimited, case-sensitive strings.?? The strings are defined by the
 authorization server.?? If the value contains multiple
space-delimited
 strings, their order does not matter, and each string adds an
 additional access range to the requested scope.???

I see 2 aspects in this definition:
- how the strings should look like is beyond the scope of the RFC
- each string adds an additional authorisation

Scopes are associated with access_tokens, which typically are
bearer tokens as defined by RFC 6750 as:
?? A security token with the property that any party in
possession of
?? the token (a "bearer") can use the token in any way that any
 

Re: [OAUTH-WG] Transaction Authorization with OAuth

[George Fletcher]

Look at this in more detail... what about calling it 
"transactional_scope" instead of "structured_scope" as the scope is 
specific to an individual transaction and not applicable across 
transactions. That would then separate it from the more capability based 
'scope' provided by OAuth2.


In this context I like the pushed-request-object method as the resource 
server is going to need to pull the same transactional requirements when 
it receives the access token.


Thanks,
George

On 4/26/19 10:17 AM, George Fletcher wrote:



On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:



Am 25.04.2019 um 17:03 schrieb George Fletcher >:



A couple of thoughts...

1. It doesn't feel like these are scopes (at least not as scope is 
defined by RFC 6749). It feels like they are more transaction 
requirements.


What???s the difference? In my opinion, if you authorize a 
transaction it???s the same. Moreover, in other use cases (account 
information) it a complex requirement for a potentially long lasting 
grant.


In both cases, they describe the request power of the token == it???s 
scope.
I guess I look at scope as "authorized to transfer" maybe something 
like "authorized to transfer up to 10K". However the details of which 
account to take the money from and the account of where to put the 
money are not aspects of the scope but rather restrictions on the 
transaction.


It may be fine to have a model where the client tells the AS what 
transaction it wants to perform for the purpose of getting consent 
from the user to perform that transaction... but I don't think the 
details of the transaction should be considered scope(s).


For me.. scope is a capability the client is authorized to perform... 
"send an Instant message", or "read a buddy list".




2. The schemas are going to be very ecosystem specific, correct?


API (e.g. all psd2 standards), ecosystem, single deployment - just 
like ???traditional??? scope values
Again, I would want the transaction requirements to be part of the API 
not part of the scope. In my mind, the authorization token should 
convey the client is authorized to perform a set of actions 
(capabilities) and then the API parameters define the exact details of 
that particular transaction.




On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:

Hi Sascha,

I see. I assume every element within the structured scope element to be an 
independent scope (value) object and intended to use the name of that object as 
kind of content type definition.

In my last example, the scope is defined as

"structured_scope":{
   "sign":{
  "credentialID":"qes_eidas",
  "documentDigests":[
 {
"hash":
  "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
"label":"Mobile Subscription Contract"
 }
  ],
  "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
   },
   "payment":{
  "type":"sepa-credit-transfer",
  "instructedAmount":{
 "currency":"EUR",
 "amount":"123.50"
  },
  "debtorAccount":{
 "iban":"DE40100100103307118608"
  },
  "creditorName":"Merchant123",
  "creditorAccount":{
 "iban":"DE02100100109307118603"
  },
  "remittanceInformationUnstructured":"new Smartphone"
   }

This means ???sign" and ???payment" would determine the scheme of the 
respective object.

What do you think?

best regards,
Torsten.


On 23. Apr 2019, at 17:14, Sascha Preibisch  wrote:

Hi Torsten!

If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!

Thank you,
Sascha

Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
:

Hi Sascha,


Am 22.04.2019 um 20:34 schrieb Sascha Preibisch:

Thank you for the article, Torsten!

my pleasure :-)


I like that 'scope' is out of the game for these kinds of authorizations.

What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.

What does profile mean in this context?

best regards,
Torsten.

Thank you,
Sascha

Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
:

Hi all,

I just published an article about the subject 
at:https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948

I look forward to getting your feedback.

kind regards,
Torsten.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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





___
OAuth mailing list
OAuth@ietf.org

Re: [OAUTH-WG] Transaction Authorization with OAuth

[George Fletcher]

On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:



Am 25.04.2019 um 17:03 schrieb George Fletcher >:



A couple of thoughts...

1. It doesn't feel like these are scopes (at least not as scope is 
defined by RFC 6749). It feels like they are more transaction 
requirements.


What???s the difference? In my opinion, if you authorize a transaction 
it???s the same. Moreover, in other use cases (account information) it a 
complex requirement for a potentially long lasting grant.


In both cases, they describe the request power of the token == it???s scope.
I guess I look at scope as "authorized to transfer" maybe something like 
"authorized to transfer up to 10K". However the details of which account 
to take the money from and the account of where to put the money are not 
aspects of the scope but rather restrictions on the transaction.


It may be fine to have a model where the client tells the AS what 
transaction it wants to perform for the purpose of getting consent from 
the user to perform that transaction... but I don't think the details of 
the transaction should be considered scope(s).


For me.. scope is a capability the client is authorized to perform... 
"send an Instant message", or "read a buddy list".




2. The schemas are going to be very ecosystem specific, correct?


API (e.g. all psd2 standards), ecosystem, single deployment - just 
like ???traditional??? scope values
Again, I would want the transaction requirements to be part of the API 
not part of the scope. In my mind, the authorization token should convey 
the client is authorized to perform a set of actions (capabilities) and 
then the API parameters define the exact details of that particular 
transaction.




On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:

Hi Sascha,

I see. I assume every element within the structured scope element to be an 
independent scope (value) object and intended to use the name of that object as 
kind of content type definition.

In my last example, the scope is defined as

"structured_scope":{
   "sign":{
  "credentialID":"qes_eidas",
  "documentDigests":[
 {
"hash":
  "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
"label":"Mobile Subscription Contract"
 }
  ],
  "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
   },
   "payment":{
  "type":"sepa-credit-transfer",
  "instructedAmount":{
 "currency":"EUR",
 "amount":"123.50"
  },
  "debtorAccount":{
 "iban":"DE40100100103307118608"
  },
  "creditorName":"Merchant123",
  "creditorAccount":{
 "iban":"DE02100100109307118603"
  },
  "remittanceInformationUnstructured":"new Smartphone"
   }

This means ???sign" and ???payment" would determine the scheme of the 
respective object.

What do you think?

best regards,
Torsten.


On 23. Apr 2019, at 17:14, Sascha Preibisch  wrote:

Hi Torsten!

If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!

Thank you,
Sascha

Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
:

Hi Sascha,


Am 22.04.2019 um 20:34 schrieb Sascha Preibisch:

Thank you for the article, Torsten!

my pleasure :-)


I like that 'scope' is out of the game for these kinds of authorizations.

What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.

What does profile mean in this context?

best regards,
Torsten.

Thank you,
Sascha

Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
:

Hi all,

I just published an article about the subject 
at:https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948

I look forward to getting your feedback.

kind regards,
Torsten.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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




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

Re: [OAUTH-WG] Transaction Authorization with OAuth (Torsten Lodderstedt)

[Pedro Igor Silva]

Hi Jaap,

Very good points. I have the same opinion about what you said about the
meaning of scopes (and how people are actually using them), the
resource-scope relationship and the importance of a standardized way of
doing this form of authorization to address different use cases, not only
delegation. Like George said in one of his messages, both 1st and 3rd party
use cases could be considered by a solution like that.

I would love to see something based on OAuth like this:

#1) Client tries to access a protected resource. At this point, the client
does not yet have a bearer token or the bearer token is lacking the
required scopes/permissions. The resource server responds with:

*HTTP/1.1 403 Unauthorized *
*WWW-Authenticate: Bearer realm="example",
error="invalid_token",
claim_token="accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC"*

The claim_token response parameter returned by the resource server
represents all the security constraints (e.g.: scopes) and information
(e.g.: contextual) that the client needs in order to obtain a valid access
token from the AS. This token can be built by the RS or even use some
endpoint at the AS, as UMA does. It can be just a reference token too.

#2) Client obtains an access token from the token endpoint at the AS:

*POST /as/token.oauth2 HTTP/1.1*
*Host: as.example.com *
*Content-Type: application/x-www-form-urlencoded*
*grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Apermission*
*=https%3A%2F%2Fbackend.example.com
%2Fapi%20*
*_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC*
*_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC*
*_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token*

The example above shows a client request to the token endpoint when the
client already has an access token and wants a new token with permissions
to access a resource.

#3) Just like any other OAuth grant type, the token endpoint responds to
the client as follows (success):

*HTTP/1.1 200 OK*
*Content-Type: application/json;charset=UTF-8*
*Cache-Control: no-store*
*Pragma: no-cache*

*{*
*"access_token":"2YotnFZFEjr1zCsicMWpAA"*
*"token_type":"example",*
*"expires_in":3600,*
*"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"*
*} *

#4) Clients can now access protected resources using the access token with
all permissions granted by the server

It is not coincidence the similarities with and the usage of specs/drafts
like token exchange, resource-indicator, UMA, Lodging Intent Pattern, or
even ACE's "AS Request Creation Hints" message. The point I would like to
make is that we could leverage the standards/specs that exist today to
address the problem without reinventing the wheel.

There are very interesting things in UMA specs that can be used here too,
such as the possibility to perform incremental authorization or token
upgrade, etc.

Regards.
Pedro Igor

On Thu, Apr 25, 2019 at 4:27 AM Jaap Francke  wrote:

> Hi Torsten and others,
>
> I just read your blog - having “we need to re-think OAuth scopes” in the
> title immediately drew my attention.
> I find this interesting since I’m struggling with the concept of scopes
> from time-to-time.
> I’ll have to read the blog a few times more to get a good understanding,
> but I would like to share some of my thoughts on scopes.
>
> I believe the OAuth scope concept has it’s limitations not only for
> transactions but also for the more traditional ‘resource’ concept.
> RFC 6749 defines scopes as follows:
> "The value of the scope parameter is expressed as a list of space-
>delimited, case-sensitive strings.  The strings are defined by the
>authorization server.  If the value contains multiple space-delimited
>strings, their order does not matter, and each string adds an
>additional access range to the requested scope.”
>
> I see 2 aspects in this definition:
> - how the strings should look like is beyond the scope of the RFC
> - each string adds an additional authorisation
>
> Scopes are associated with access_tokens, which typically are bearer
> tokens as defined by RFC 6750 as:
>   A security token with the property that any party in possession of
>   the token (a "bearer") can use the token in any way that any other
>   party in possession of it can.  Using a bearer token does not
>   require a bearer to prove possession of cryptographic key material
>   (proof-of-possession).”
>
> This implies that every scope value should fully describe the
> authorisation that is given. In my view that is rarely done, which is the
> main reason why I find myself struggling with scope-concept.
>
> Here we have a collection of examples, which demonstrate to me that
> everyone is inventing their own wheels according to their specfic needs:
> https://brandur.org/oauth-scope
> https://api.slack.com/docs/oauth-scopes
>
> In various other (draft) standards I see bits and pieces that seem to
> address this issue.
>
> In UMA an authorisation is conceptually broken 

[OAUTH-WG] Formal analysis of draft-ietf-oauth-pop-key-distribution

[Luca Arnaboldi]

* I spoke with Hannes after the IETF meeting in Prague and he expressed the 
need to enhance our formal analysis (as presented at the OAuth Security 
Workshop) to verify whether it is necessary to demonstrate possession of the 
private key by the client to the authorization server.


* The analysis checked whether it was necessary for a proof of possession to be 
performed between the client and AS to ensure security. The result was that 
even without verification by the AS the client would not be able to access the 
resource from the RS without possessing the secret key associated to the token 
(assuming the check is done correctly by the RS).

Tamarin model for specific example with proofs available at : 
https://github.com/Yiergot/ACE-OAuth-FormalModel


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization with OAuth

[Takahiko Kawasaki]

Dear Torsten,

I was impressed with your article. It describes considerations points very
well that implementers of leading-edge authorization servers will
eventually face or have already faced.

It seems to me that the mechanism of "structured_scope" can be positioned
as a more generic mechanism whose usage doesn't necessarily have to be
limited to scopes. I mean that the mechanism can be used to include any
arbitrary dynamic structured data in an authorization request. So, if there
were something I might be able to propose additionally, I would suggest
renaming "structured_scope" to a more generic name.

Best Regards,
Takahiko Kawasaki
Representative director, Authlete, Inc.

2019年4月21日(日) 3:21 Torsten Lodderstedt :

> Hi all,
>
> I just published an article about the subject at:
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>
>
> I look forward to getting your feedback.
>
> kind regards,
> Torsten.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth