[OAUTH-WG] Fwd: Internet Privacy Workshop: 8 and 9 December 2010

[Hannes Tschofenig]

I believe that this workshop is relevant to this group. You may consider 
submitting a position paper. 

Ciao
Hannes

Begin forwarded message:

> From: IETF Secretariat 
> Date: September 21, 2010 12:00:02 AM GMT+03:00
> To: ietf-annou...@ietf.org
> Subject: Internet Privacy Workshop: 8 and 9 December 2010 
> 
> The Internet Architecture Board (IAB), World Wide Web Consortium (W3C),
> Internet Society (ISOC) and Massachusetts Institute of Technology (MIT)
> will hold a joint Internet privacy workshop on 8 and 9 December 2010 at
> MIT, Cambridge, Massachusetts on the question:
> 
> "How Can Technology Help to Improve Privacy on the Internet?"
> 
> Information about who we are, what we own, what we have experienced, how
> we behave, where we are located, and how we can be reached are among the
> most personal pieces of information about us. This information is
> increasingly being made more easily available electronically via the
> Internet, often without the consent of the subject.
> 
> The question for the workshop therefore is: How can we ensure that
> architectures and technologies for the Internet, including the World
> Wide Web, are developed in ways that respects users‚ intentions about
> their privacy?
> 
> This workshop aims to explore the experience and approaches taken by
> developers of Internet including Web technology, when designing privacy
> into these protocols and architectures. Engineers know that many design
> considerations need to be taken into account when developing solutions.
> Balancing between the conflicting goals of openness, privacy, economics,
> and security is often difficult, as illustrated by Clark, et al. in
> "Tussle in Cyberspace: Defining Tomorrow's Internet", see
> http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf
> 
> As a member of the technical community, we invite you to share your
> experiences by participating in this important workshop. Workshop
> participants will focus on the core privacy challenges, the approaches
> taken to deal with them, and the status of the work in the field. The
> objective is to draw a relationship with other application areas and
> other privacy work in an effort to discuss how specific approaches can
> be generalized.
> 
> Interested parties must submit a brief contribution describing their
> work or approach as it relates to the workshop theme. We welcome
> visionary ideas for how to tackle Internet privacy problems, as well as
> write-ups of existing concepts, deployed technologies, and
> lessons-learned from successful or failed attempts at deploying privacy
> technologies. Contributions are not required to be original in content.
> 
> Submitters of accepted position papers will be invited to the workshop.
> The workshop will be structured as a series of working sessions,
> punctuated by invited speakers, who will present relevant background
> information or controversial ideas that will motivate participants to
> reach a deeper understanding of the subject. The organizing committee
> may ask submitters of particularly topical papers to present their ideas
> and experiences to the workshop.
> 
> We will publish submitted position papers and slides together with a
> summary report of the workshop.
> 
> There are no plans for any remote participation in this workshop.
> 
> To be invited to the workshop, please submit position papers to
> priv...@iab.org by November, 5th 2010.
> 
> More detailed information about the workshop, including further details
> about the position paper requirements, is available at:
> http://www.iab.org/about/workshops/privacy/
> 
> We look forward to your input,
> Bernard Aboba (IAB), Trent Adams (ISOC), Daniel Appelquist (W3C), Karen
> O'Donoghue (ISOC), Jon Peterson (IAB), Thomas Roessler (W3C), Karen
> Sollins (MIT), Hannes Tschofenig (IAB)
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

Re: [OAUTH-WG] Not requiring client registration

[Francisco Corella]

I forgot to acknowledge in my previous message that the work that let to the 
proposal was supported by NSF grant IIP-1013594.

--- On Thu, 9/23/10, Francisco Corella  wrote:

From: Francisco Corella 
Subject: Not requiring client registration
To: oauth@ietf.org
Date: Thursday, September 23, 2010, 3:31 AM

Hello,

I'm new to the list.  I've signed up to propose a simple improvement that would 
avoid the need for the OAuth client to register with the resource server.  
Registration may seem necessary because it provides information that the 
resource server can use to tell the user what client is requesting a resource.  
But there are alternatives: in the solution I describe below, the resource 
server describes the client to the user using information contained in an 
ordinary TLS server certificate presented by the OAuth client during an 
ordinary TLS handshake.

Eliminating the need for registration would have many benefits.  Consider the 
photo sharing/printing example of the Internet draft, and assume that there is 
a standard Web API that printing services can use to access photo sharing 
services.  (Is there such a thing?  If
 not there will no doubt be one in the future.)  A new photo sharing service 
would benefit because its users could use any printing service, and because it 
would not have to implement and maintain a registration service.  A photo 
printing service would benefit because it could print photos from any photo 
sharing service implementing the standard API, without having to register or 
even be aware of the existence of the photo sharing service.  (The user would 
provide the url of the sharing service.)  And a user would benefit by being 
less constrained in her choice of photo-sharing-and-printing solutions.

Here is the proposal.  I assume that the OAuth client runs in a web server 
("web server profile").  The user asks the OAuth client to access a resource on 
its behalf.  The OAuth client redirects the user-agent to the resource server, 
but instead of including a client identifier in the redirection url, it 
includes a
 url pointing to a web server owned by the OAuth client, from which the 
resource server downloads a self-signed TLS client certificate that the OAuth 
client will later use for authentication in a TLS handshake.  This url is an 
https url, and the resource server obtains the OAuth client's server 
certificate during the TLS handshake.

(Note: the OAuth client has two certificates, a TLS client certificate and a 
TLS server certificate.  A single dual-purpose certificate could play both 
roles, but I don't see an advantage to this.)

The resource server asks permission from the user to provide the resource to 
the OAuth client, describing the Oauth client to the user based on the 
information included the server certificate, and perhaps telling the user what 
CA backs the server certificate.  Assume the user grants permission.

The resource server stores the OAuth client's self-signed client certificate, 
pairing it with an
 authorization code, and places the authorization code in a redirection url 
that redirects the user-agent back to the OAuth client.  The OAuth client uses 
the authorization code to request the resource over a TLS connection, in which 
it authenticates itself using the self-signed client certificate.  The resource 
server verifies the self-signed client certificate by checking that it had 
earlier stored it, paired with the authorization code.

Does this make sense?

Francisco
---
Francisco Corella
CEO, Pomcor
fcorella at pomcor dot com

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

Re: [OAUTH-WG] Simpilfying use of assertions when requesting an access token

[Brian Campbell]

Do parameters defined by grant types really need a registry?  I mean,
a client only presents one access grant request at a time so it's not
like there's potential for name conflicts. Am I missing something?



On Wed, Sep 22, 2010 at 10:53 AM, Eran Hammer-Lahav  wrote:
> It's a question of use cases. Right now, a single assertion parameter seems 
> to be useful. But there is no strong reason why the SAML spec can't register 
> that as an extension. The thing is, once that is done, other specs using the 
> same parameter (say, a future SAML spec for a newer version) will need to 
> update the registry and potentially the RFC of the extension... Not pretty.
>
> So if we have consensus that an assertion parameter is better than a saml2 
> and saml3 parameters for each extension, I'd say keep it in.
>
> EHL
>
>> -Original Message-
>> From: Brian Campbell [mailto:bcampb...@pingidentity.com]
>> Sent: Tuesday, September 21, 2010 3:20 PM
>> To: Justin Richer
>> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
>> Subject: Re: [OAUTH-WG] Simpilfying use of assertions when requesting an
>> access token
>>
>> I'm not sure one email from me asking for clarification exactly counts
>> as a movement ;-)   I was just thinking that it'd be more consistent
>> to have each uri-defined grant type define it's own parameter set.
>> Really this is what is already happening with the core defined short names -
>> the "authorization_code" grant type defines the "code" param, the
>> "password" grant type defines the "username" and "password"
>> params, and "refresh_token" defines "refresh_token".   The
>> "client_credentials" grant type is a little different in that it doesn't 
>> directly
>> define parameters but defers to a different part of the spec to do that but a
>> uri extension could conceivably do something similar (point to other specs or
>> other layers in the protocol stack or whatever).
>>
>> Having said all that, however, I do see the logic in what you said about 
>> having
>> the one assertion parameter.  But, I dunno, it just seems a little awkward
>> there all by itself.
>>
>>
>> On Tue, Sep 21, 2010 at 3:30 PM, Justin Richer  wrote:
>> > I personally think it makes a certain amount of sense to have the
>> > assertion parameter: if you have only one thing to say, here's where
>> > to say it. And I think that we've got a few cases of assertions with
>> > only a single string to assert. However, I was always concerned with
>> > that single parameter as the *only* allowed parameter, which Eran has
>> > said won't be a problem. That said, if there's a movement for dropping
>> > it in favor of extension-defined parameter sets, I won't block it.
>> >
>> >  -- Justin
>> >
>> > On Tue, 2010-09-21 at 17:11 -0400, Brian Campbell wrote:
>> >> Following from that (Justin: "url-defined grant type can also legally
>> >> add and remove parameters from the endpoint, right?" / Eran: "Yes")
>> >> does the assertion parameter still make sense to have in the core
>> >> spec?  I had sort of assumed that it would be going away in favor of
>> >> whatever parameters any url-defined grant type would deem necessary.
>> >> However, Eran's "working copy" of draft -11 as of 2010-09-03 still
>> >> has the assertion parameter.  Is that area still being worked on or
>> >> was the intent to leave the parameter in for -11?
>> >>
>> >>
>> >> On Thu, Sep 2, 2010 at 3:28 PM, Eran Hammer-Lahav
>>  wrote:
>> >> > Yes.
>> >> >
>> >> > -Original Message-
>> >> > From: Justin Richer [mailto:jric...@mitre.org]
>> >> > Sent: Thursday, September 02, 2010 2:27 PM
>> >> > To: Eran Hammer-Lahav
>> >> > Cc: OAuth WG (oauth@ietf.org)
>> >> > Subject: Re: [OAUTH-WG] Simpilfying use of assertions when
>> >> > requesting an access token
>> >> >
>> >> > +1
>> >> >
>> >> > I've never liked the notion of not being able to extend the "grant type"
>> >> > field, and this change addresses that particular gripe.
>> >> >
>> >> > Just so I'm clear here: an extension that defines its own url-defined
>> grant type can also legally add and remove parameters from the endpoint,
>> right?
>> >> >
>> >> >  -- Justin
>> >> >
>> >> > On Thu, 2010-09-02 at 17:11 -0400, Eran Hammer-Lahav wrote:
>> >> >> I would like to make this change in -11:
>> >> >>
>> >> >>
>> >> >>
>> >> >> Instead of the current user of the 'assertion' grant type -
>> >> >>
>> >> >>
>> >> >>
>> >> >>   POST /token HTTP/1.1
>> >> >>
>> >> >>   Host: server.example.com
>> >> >>
>> >> >>   Content-Type: application/x-www-form-urlencoded
>> >> >>
>> >> >>
>> >> >>
>> >> >>   grant_type=assertion&
>> >> >>
>> >> >>
>> >> >>
>> assertion_type=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertio
>> n&
>> >> >>
>> >> >>   assertion=PHNhbWxwOl[...omitted for brevity...]ZT4%3D
>> >> >>
>> >> >>
>> >> >>
>> >> >> Drop the 'assertion' grant type and put the assertion type
>> >> >> directly in the grant_type parameter:
>> >> >>
>> >> >>
>> >> >>
>> >> >>   POST /token HTTP/1.1
>> >> >>
>> >> >>   Host: server.example

Re: [OAUTH-WG] Simpilfying use of assertions when requesting an access token

[Marius Scurtescu]

On Thu, Sep 23, 2010 at 2:08 PM, Brian Campbell
 wrote:
> Do parameters defined by grant types really need a registry?  I mean,
> a client only presents one access grant request at a time so it's not
> like there's potential for name conflicts. Am I missing something?

There could be conflicts with other extensions that send parameters
alongside a grant request, no?

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

[OAUTH-WG] Signatures spec proposal, take 2

[Dirk Balfanz]

Hi guys,

sorry it took a while, but here is an updated proposal. It's still in three
parts:

Part I is about "JSON Tokens" that can be used for all sorts of things, not
just OAuth:
http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html

Part II is about how to embed an OAuth token and (some parts of) an HTTP
request into a JSON Token:
http://balfanz.github.com/jsontoken-spec/draft-balfanz-signedoauth2-00.html

Part III is how to use signatures instead of client secrets for assertions
in OAuth:
http://balfanz.github.com/jsontoken-spec/draft-balfanz-clientassertions-00.html

Diffs from the last specs are:

- JSON Tokens are now just a profile of Magic Signatures, which John Panzer
has helpfully extended for this purpose
- There was a vulnerability to masquerading attacks in the last proposal,
which is addressed in this proposal by adding a data_type parameter that is
part of the signature, but _not_ part of the payload.
- no more support of X.509 certs - the only supported format for discovered
public keys is now the Magic Key format. We'll give people tools (which are
quite easy to write) to convert their self-signed or CA-issued certs to
magic keys.
- The specs are now formatted as I-Ds.

Comments, please!

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

[OAUTH-WG] Google's view on signatures in the core OAuth2 spec

[Eric Sachs]

Google wanted to re-state our long standing opinions on HTTP signature
mechanisms in the OAuth2 spec.  The short version is that standards for
signing parts of an HTTP request have value in use-cases other than OAuth2,
and thus they should be defined outside the spec, and just referenced from
the spec similar to how we reference other Internet security building blocks
like SSL.  Those signature standards are likely to in turn reference
optional mechanisms for key rotation and discovery, as well as reference
different crypto schemes like HMAC or RSA.

There are already people in the identity community working on specs that are
related to OAuth2, but which have value in other use-cases.  For example,
there are people working on defining standards around token formats, signing
blobs of different types (such as a token and/or HTTP request), key
discovery/rotation, and consumer-key namespaces across vendors.  Dirk
Balfanz from Google recently sent out updated drafts of some of those specs,
and they also leverage specs that John Panzer from Google has worked on for
Magic Signatures, as well as input from people in the community who are not
at Google.

However even though Google is working on those specs, we still believe it is
a mistake to delay the OAuth2 core spec standard to wait on broad agreement
for a "signature proposal," just as it would be a mistake to delay the
OAuth2 core spec to wait on the standards efforts around token formats,
token signing, key discovery/rotation, consumer-key naming, etc.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JSON Web Token (JWT) Specification Draft

[Mike Jones]

FYI, I've also posted this at 
http://self-issued.info/docs/draft-goland-json-web-token-00.html and 
http://self-issued.info/docs/draft-goland-json-web-token-00.xml for easy 
reference by those who didn't receive the original attachments.

-- Mike

From: Mike Jones
Sent: Thursday, September 23, 2010 5:22 PM
To: 'oauth@ietf.org'
Cc: Yaron Goland
Subject: JSON Web Token (JWT) Specification Draft

Recognizing that there is substantial interest in representing sets of claims 
in JSON tokens, Yaron Goland and I have put together a draft JSON Web Token 
(JWT) spec for that purpose.

To answer the obvious question, while this was produced independently of Dirk's 
JSON token 
proposal,
 both of us agree that we should come up with a unified spec.  Consider this an 
additional point in the possible design space from which to start discussions 
and drive consensus.  (If you read the two proposals, I think you'll find that 
there's already a lot in common, which is great.)

Thanks to those of you who have already given us feedback to improve the draft 
prior to this point.

Cheers,
-- Mike

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

Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

[Anthony Nadalin]

Eric, Microsoft shares some of the same views, we would like to see the WG 
charter expanded to cover these additional items (so we have a home for these), 
we would like to see that proposed and agreed upon at the November meeting if 
at all possible.

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eric 
Sachs
Sent: Thursday, September 23, 2010 5:30 PM
To: OAuth WG
Subject: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

Google wanted to re-state our long standing opinions on HTTP signature 
mechanisms in the OAuth2 spec.  The short version is that standards for signing 
parts of an HTTP request have value in use-cases other than OAuth2, and thus 
they should be defined outside the spec, and just referenced from the spec 
similar to how we reference other Internet security building blocks like SSL.  
Those signature standards are likely to in turn reference optional mechanisms 
for key rotation and discovery, as well as reference different crypto schemes 
like HMAC or RSA.

There are already people in the identity community working on specs that are 
related to OAuth2, but which have value in other use-cases.  For example, there 
are people working on defining standards around token formats, signing blobs of 
different types (such as a token and/or HTTP request), key discovery/rotation, 
and consumer-key namespaces across vendors.  Dirk Balfanz from Google recently 
sent out updated drafts of some of those specs, and they also leverage specs 
that John Panzer from Google has worked on for Magic Signatures, as well as 
input from people in the community who are not at Google.

However even though Google is working on those specs, we still believe it is a 
mistake to delay the OAuth2 core spec standard to wait on broad agreement for a 
"signature proposal," just as it would be a mistake to delay the OAuth2 core 
spec to wait on the standards efforts around token formats, token signing, key 
discovery/rotation, consumer-key naming, etc.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

[Eran Hammer-Lahav]

It is pretty clear from the recent public response that a core specification 
without signatures is going to be viewed as weak and insecure. This has been my 
position for over a year, and if it wasn't clear, I am going to continue 
expressing it.

We have enough interest to get a basic signature support in the core 
specification, one that is not driven by enterprise use cases, complex identity 
solutions, or large distributed systems. Given the recent Twitter migration to 
OAuth 1.0a proved that with a big enough carrot (or stick, depending on your 
view), developers figure it out. I believe that an OAuth 1.0a style signature 
can be easily developed and added to the core specification as an optional 
feature.

This is not new. This was agreed upon at the Anaheim meeting. I took the 
signature language out of the draft in order to focus the discussion on the 
other components. Now that -10 is pretty solid (normative language-wise), it is 
time to bring it back in.

Draft -11 will include a signature proposal, even if that means a short delay.

The arguments about delaying the core spec are meritless, given that a growing 
number of companies are releasing OAuth 2.0 APIs using the latest stable draft. 
We can easily do a WGLC for the current stable components, and add signatures 
without changing those. This working group does not make technical and 
architectural decisions based on the timeline needs of any company. We do what 
is best for the web and we take as much time as necessary.

As an aside, while companies can certainly express their corporate position on 
matters, this is a working group of individuals, and consensus is based solely 
on individual voices.

EHL






On 9/23/10 5:30 PM, "Eric Sachs"  wrote:

Google wanted to re-state our long standing opinions on HTTP signature 
mechanisms in the OAuth2 spec.  The short version is that standards for signing 
parts of an HTTP request have value in use-cases other than OAuth2, and thus 
they should be defined outside the spec, and just referenced from the spec 
similar to how we reference other Internet security building blocks like SSL.  
Those signature standards are likely to in turn reference optional mechanisms 
for key rotation and discovery, as well as reference different crypto schemes 
like HMAC or RSA.

There are already people in the identity community working on specs that are 
related to OAuth2, but which have value in other use-cases.  For example, there 
are people working on defining standards around token formats, signing blobs of 
different types (such as a token and/or HTTP request), key discovery/rotation, 
and consumer-key namespaces across vendors.  Dirk Balfanz from Google recently 
sent out updated drafts of some of those specs, and they also leverage specs 
that John Panzer from Google has worked on for Magic Signatures, as well as 
input from people in the community who are not at Google.

However even though Google is working on those specs, we still believe it is a 
mistake to delay the OAuth2 core spec standard to wait on broad agreement for a 
"signature proposal," just as it would be a mistake to delay the OAuth2 core 
spec to wait on the standards efforts around token formats, token signing, key 
discovery/rotation, consumer-key naming, etc.

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

Re: [OAUTH-WG] JSON Web Token (JWT) Specification Draft

[Eran Hammer-Lahav]

Why aren't these published as an IETF I-D?

EHL


On 9/23/10 5:40 PM, "Mike Jones"  wrote:

FYI, I've also posted this at 
http://self-issued.info/docs/draft-goland-json-web-token-00.html and 
http://self-issued.info/docs/draft-goland-json-web-token-00.xml for easy 
reference by those who didn't receive the original attachments.

-- Mike


From: Mike Jones
Sent: Thursday, September 23, 2010 5:22 PM
To: 'oauth@ietf.org'
Cc: Yaron Goland
Subject: JSON Web Token (JWT) Specification Draft

Recognizing that there is substantial interest in representing sets of claims 
in JSON tokens, Yaron Goland and I have put together a draft JSON Web Token 
(JWT) spec for that purpose.

To answer the obvious question, while this was produced independently of Dirk's 
JSON token proposal 
 , 
both of us agree that we should come up with a unified spec.  Consider this an 
additional point in the possible design space from which to start discussions 
and drive consensus.  (If you read the two proposals, I think you'll find that 
there's already a lot in common, which is great.)

Thanks to those of you who have already given us feedback to improve the draft 
prior to this point.

Cheers,
-- Mike


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

Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

[Anthony Nadalin]

I have not seen the support to bring signature support back into core, have not 
seen the public response either, all I have seen is you raising this as an 
issue. We should keep the original agreement to move signatures out of core, 
there is enough activity on signatures that we are confident that it will 
proceed as a separate item.

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran 
Hammer-Lahav
Sent: Thursday, September 23, 2010 6:12 PM
To: Eric Sachs; OAuth WG
Subject: Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

It is pretty clear from the recent public response that a core specification 
without signatures is going to be viewed as weak and insecure. This has been my 
position for over a year, and if it wasn't clear, I am going to continue 
expressing it.

We have enough interest to get a basic signature support in the core 
specification, one that is not driven by enterprise use cases, complex identity 
solutions, or large distributed systems. Given the recent Twitter migration to 
OAuth 1.0a proved that with a big enough carrot (or stick, depending on your 
view), developers figure it out. I believe that an OAuth 1.0a style signature 
can be easily developed and added to the core specification as an optional 
feature.

This is not new. This was agreed upon at the Anaheim meeting. I took the 
signature language out of the draft in order to focus the discussion on the 
other components. Now that -10 is pretty solid (normative language-wise), it is 
time to bring it back in.

Draft -11 will include a signature proposal, even if that means a short delay.

The arguments about delaying the core spec are meritless, given that a growing 
number of companies are releasing OAuth 2.0 APIs using the latest stable draft. 
We can easily do a WGLC for the current stable components, and add signatures 
without changing those. This working group does not make technical and 
architectural decisions based on the timeline needs of any company. We do what 
is best for the web and we take as much time as necessary.

As an aside, while companies can certainly express their corporate position on 
matters, this is a working group of individuals, and consensus is based solely 
on individual voices.

EHL






On 9/23/10 5:30 PM, "Eric Sachs"  wrote:
Google wanted to re-state our long standing opinions on HTTP signature 
mechanisms in the OAuth2 spec.  The short version is that standards for signing 
parts of an HTTP request have value in use-cases other than OAuth2, and thus 
they should be defined outside the spec, and just referenced from the spec 
similar to how we reference other Internet security building blocks like SSL.  
Those signature standards are likely to in turn reference optional mechanisms 
for key rotation and discovery, as well as reference different crypto schemes 
like HMAC or RSA.

There are already people in the identity community working on specs that are 
related to OAuth2, but which have value in other use-cases.  For example, there 
are people working on defining standards around token formats, signing blobs of 
different types (such as a token and/or HTTP request), key discovery/rotation, 
and consumer-key namespaces across vendors.  Dirk Balfanz from Google recently 
sent out updated drafts of some of those specs, and they also leverage specs 
that John Panzer from Google has worked on for Magic Signatures, as well as 
input from people in the community who are not at Google.

However even though Google is working on those specs, we still believe it is a 
mistake to delay the OAuth2 core spec standard to wait on broad agreement for a 
"signature proposal," just as it would be a mistake to delay the OAuth2 core 
spec to wait on the standards efforts around token formats, token signing, key 
discovery/rotation, consumer-key naming, etc.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

[Eric Sachs]

>> I believe that an OAuth 1.0a style signature
How about we start with exactly an OAuth 1.0a style signature?  It may be
tricky, but there are still client libraries and some web-services that
handle them.

Like Tony, I also have not heard requests for a new signature approach, but
one of the reasons is that there are already developers who are using OAuth2
& WRAP style approaches combined with OAuth1 signatures.  So why not simply
have a section in the core spec that mentions the option of using signatures
and gives OAuth1 as one of the possible approaches?

That avoids the potential concern of any large delay in the core spec to get
agreement on a new signature mechanism, but gives an option that can quickly
be used by developers, and provides a place to hook in other signature
schemes in the future.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

[Dick Hardt]

I agree with your point that consensus is based on individual voices.

I agree with Eric's points that signatures are a generic security mechanism and 
that signatures should be in a separate spec. 

-- Dick


On 2010-09-23, at 6:11 PM, Eran Hammer-Lahav wrote:

> It is pretty clear from the recent public response that a core specification 
> without signatures is going to be viewed as weak and insecure. This has been 
> my position for over a year, and if it wasn’t clear, I am going to continue 
> expressing it.
> 
> We have enough interest to get a basic signature support in the core 
> specification, one that is not driven by enterprise use cases, complex 
> identity solutions, or large distributed systems. Given the recent Twitter 
> migration to OAuth 1.0a proved that with a big enough carrot (or stick, 
> depending on your view), developers figure it out. I believe that an OAuth 
> 1.0a style signature can be easily developed and added to the core 
> specification as an optional feature.
> 
> This is not new. This was agreed upon at the Anaheim meeting. I took the 
> signature language out of the draft in order to focus the discussion on the 
> other components. Now that –10 is pretty solid (normative language-wise), it 
> is time to bring it back in.
> 
> Draft –11 will include a signature proposal, even if that means a short delay.
> 
> The arguments about delaying the core spec are meritless, given that a 
> growing number of companies are releasing OAuth 2.0 APIs using the latest 
> stable draft. We can easily do a WGLC for the current stable components, and 
> add signatures without changing those. This working group does not make 
> technical and architectural decisions based on the timeline needs of any 
> company. We do what is best for the web and we take as much time as necessary.
> 
> As an aside, while companies can certainly express their corporate position 
> on matters, this is a working group of individuals, and consensus is based 
> solely on individual voices.
> 
> EHL
> 
> 
> 
> 
> 
> 
> On 9/23/10 5:30 PM, "Eric Sachs"  wrote:
> 
> Google wanted to re-state our long standing opinions on HTTP signature 
> mechanisms in the OAuth2 spec.  The short version is that standards for 
> signing parts of an HTTP request have value in use-cases other than OAuth2, 
> and thus they should be defined outside the spec, and just referenced from 
> the spec similar to how we reference other Internet security building blocks 
> like SSL.  Those signature standards are likely to in turn reference optional 
> mechanisms for key rotation and discovery, as well as reference different 
> crypto schemes like HMAC or RSA.
> 
> There are already people in the identity community working on specs that are 
> related to OAuth2, but which have value in other use-cases.  For example, 
> there are people working on defining standards around token formats, signing 
> blobs of different types (such as a token and/or HTTP request), key 
> discovery/rotation, and consumer-key namespaces across vendors.  Dirk Balfanz 
> from Google recently sent out updated drafts of some of those specs, and they 
> also leverage specs that John Panzer from Google has worked on for Magic 
> Signatures, as well as input from people in the community who are not at 
> Google.
> 
> However even though Google is working on those specs, we still believe it is 
> a mistake to delay the OAuth2 core spec standard to wait on broad agreement 
> for a "signature proposal," just as it would be a mistake to delay the OAuth2 
> core spec to wait on the standards efforts around token formats, token 
> signing, key discovery/rotation, consumer-key naming, etc.
> 
> ___
> 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-WG] Basic signature support in the core specification

[Eran Hammer-Lahav]

Since much of this recent debate was done off list, I'd like to ask people
to simply express their support or objection to including a basic signature
feature in the core spec, in line with the 1.0a signature approach.

This is not a vote, just taking the temperature of the group.

EHL

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

Re: [OAUTH-WG] Signatures spec proposal, take 2

[Eran Hammer-Lahav]

In part II, how is the signature bound to the HTTP request URI? I see the 
method and body, but not the request URI.

EHL


On 9/23/10 3:39 PM, "Dirk Balfanz"  wrote:

Hi guys,

sorry it took a while, but here is an updated proposal. It's still in three 
parts:

Part I is about "JSON Tokens" that can be used for all sorts of things, not 
just OAuth:
http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html

Part II is about how to embed an OAuth token and (some parts of) an HTTP 
request into a JSON Token:
http://balfanz.github.com/jsontoken-spec/draft-balfanz-signedoauth2-00.html

Part III is how to use signatures instead of client secrets for assertions in 
OAuth:
http://balfanz.github.com/jsontoken-spec/draft-balfanz-clientassertions-00.html

Diffs from the last specs are:

- JSON Tokens are now just a profile of Magic Signatures, which John Panzer has 
helpfully extended for this purpose
- There was a vulnerability to masquerading attacks in the last proposal, which 
is addressed in this proposal by adding a data_type parameter that is part of 
the signature, but _not_ part of the payload.
- no more support of X.509 certs - the only supported format for discovered 
public keys is now the Magic Key format. We'll give people tools (which are 
quite easy to write) to convert their self-signed or CA-issued certs to magic 
keys.
- The specs are now formatted as I-Ds.

Comments, please!

Dirk.


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

Re: [OAUTH-WG] Signatures spec proposal, take 2

[Dirk Balfanz]

On Thu, Sep 23, 2010 at 6:51 PM, Eran Hammer-Lahav wrote:

>  In part II, how is the signature bound to the HTTP request URI? I see the
> method and body, but not the request URI.
>

The request URI goes in the audience parameter that's defined in part I.

Dirk.


>
> EHL
>
>
>
> On 9/23/10 3:39 PM, "Dirk Balfanz"  wrote:
>
> Hi guys,
>
> sorry it took a while, but here is an updated proposal. It's still in three
> parts:
>
> Part I is about "JSON Tokens" that can be used for all sorts of things, not
> just OAuth:
> http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html
>
> Part II is about how to embed an OAuth token and (some parts of) an HTTP
> request into a JSON Token:
> http://balfanz.github.com/jsontoken-spec/draft-balfanz-signedoauth2-00.html
>
> Part III is how to use signatures instead of client secrets for assertions
> in OAuth:
>
> http://balfanz.github.com/jsontoken-spec/draft-balfanz-clientassertions-00.html
>
> Diffs from the last specs are:
>
> - JSON Tokens are now just a profile of Magic Signatures, which John Panzer
> has helpfully extended for this purpose
> - There was a vulnerability to masquerading attacks in the last proposal,
> which is addressed in this proposal by adding a data_type parameter that is
> part of the signature, but _not_ part of the payload.
> - no more support of X.509 certs - the only supported format for discovered
> public keys is now the Magic Key format. We'll give people tools (which are
> quite easy to write) to convert their self-signed or CA-issued certs to
> magic keys.
> - The specs are now formatted as I-Ds.
>
> Comments, please!
>
> Dirk.
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures spec proposal, take 2

[Eran Hammer-Lahav]

First, thanks for putting this together. It provides a pretty comprehensive 
story about the signed tokens proposal. I don't have much to add at this point 
to the drafts.

My position, which I have expressed many times before about this approach is:

Any solution involving repeating the HTTP request elements in some sort of 
envelope will require validation .In this case, you need to define all the 
rules for validating the 'audience' parameter.

This approach makes it too tempting for server developers to ignore the HTTP 
request and only use the values of the 'audience' and 'method' parameters. In 
order to validate those parameters, the server needs to perform some sort of 
normalization (which eventually leads to the same signature mismatch problems). 
Not looking at the HTTP request will lead to security problems because it will 
allow bypassing existing HTTP firewall rules which operate on the request URI 
and HTTP method.

As a matter of personal taste, this smells too much like SOAP. And that's a 
really bad thing.

I am not in favor of any solution that replicates components of the HTTP 
request within the request (as is the case here). Recent experience shows that 
with a little help and good libraries, developers can figure out how to 
normalize and sign an HTTP request successfully, when motivated.

EHL


On 9/23/10 7:07 PM, "Dirk Balfanz"  wrote:



On Thu, Sep 23, 2010 at 6:51 PM, Eran Hammer-Lahav  wrote:
In part II, how is the signature bound to the HTTP request URI? I see the 
method and body, but not the request URI.

The request URI goes in the audience parameter that's defined in part I.

Dirk.


EHL



On 9/23/10 3:39 PM, "Dirk Balfanz" http://balf...@google.com> > wrote:

Hi guys,

sorry it took a while, but here is an updated proposal. It's still in three 
parts:

Part I is about "JSON Tokens" that can be used for all sorts of things, not 
just OAuth:
http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html

Part II is about how to embed an OAuth token and (some parts of) an HTTP 
request into a JSON Token:
http://balfanz.github.com/jsontoken-spec/draft-balfanz-signedoauth2-00.html

Part III is how to use signatures instead of client secrets for assertions in 
OAuth:
http://balfanz.github.com/jsontoken-spec/draft-balfanz-clientassertions-00.html

Diffs from the last specs are:

- JSON Tokens are now just a profile of Magic Signatures, which John Panzer has 
helpfully extended for this purpose
- There was a vulnerability to masquerading attacks in the last proposal, which 
is addressed in this proposal by adding a data_type parameter that is part of 
the signature, but _not_ part of the payload.
- no more support of X.509 certs - the only supported format for discovered 
public keys is now the Magic Key format. We'll give people tools (which are 
quite easy to write) to convert their self-signed or CA-issued certs to magic 
keys.
- The specs are now formatted as I-Ds.

Comments, please!

Dirk.




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

Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

[Richard L. Barnes]

I also agree with the observation about consensus being based on  
individual voices.


I don't think it's accurate to say that signatures are a generic  
security mechanism.  As I would think we learned from OAuth 1.0[a], it  
can actually be pretty subtle to define how signatures are used in a  
given context.


I doubt that a spec that only includes a "bearer token" model will not  
have enough of a security story to get past SECDIR and IESG review,  
especially without some careful thinking about when TLS is required  
and how it is negotiated (for example, you may need something like  
HSTS [1]).


On the other hand, it seems like a sensible compromise approach to re- 
use the signature scheme from OAuth 1.0a.  If there is interest in  
some other type of signing scheme, then of course the cost of this  
approach is having some sort of versioning / negotiation for signature  
algorithms.  But this may already be necessary to distinguish between  
signed requests and bearer-token requests.


--Richard

[1] 




On Sep 23, 2010, at 9:30 PM, Dick Hardt wrote:


I agree with your point that consensus is based on individual voices.

I agree with Eric's points that signatures are a generic security  
mechanism and that signatures should be in a separate spec.


-- Dick


On 2010-09-23, at 6:11 PM, Eran Hammer-Lahav wrote:

It is pretty clear from the recent public response that a core  
specification without signatures is going to be viewed as weak and  
insecure. This has been my position for over a year, and if it  
wasn’t clear, I am going to continue expressing it.


We have enough interest to get a basic signature support in the  
core specification, one that is not driven by enterprise use cases,  
complex identity solutions, or large distributed systems. Given the  
recent Twitter migration to OAuth 1.0a proved that with a big  
enough carrot (or stick, depending on your view), developers figure  
it out. I believe that an OAuth 1.0a style signature can be easily  
developed and added to the core specification as an optional feature.


This is not new. This was agreed upon at the Anaheim meeting. I  
took the signature language out of the draft in order to focus the  
discussion on the other components. Now that –10 is pretty solid  
(normative language-wise), it is time to bring it back in.


Draft –11 will include a signature proposal, even if that means a  
short delay.


The arguments about delaying the core spec are meritless, given  
that a growing number of companies are releasing OAuth 2.0 APIs  
using the latest stable draft. We can easily do a WGLC for the  
current stable components, and add signatures without changing  
those. This working group does not make technical and architectural  
decisions based on the timeline needs of any company. We do what is  
best for the web and we take as much time as necessary.


As an aside, while companies can certainly express their corporate  
position on matters, this is a working group of individuals, and  
consensus is based solely on individual voices.


EHL






On 9/23/10 5:30 PM, "Eric Sachs"  wrote:

Google wanted to re-state our long standing opinions on HTTP  
signature mechanisms in the OAuth2 spec.  The short version is that  
standards for signing parts of an HTTP request have value in use- 
cases other than OAuth2, and thus they should be defined outside  
the spec, and just referenced from the spec similar to how we  
reference other Internet security building blocks like SSL.  Those  
signature standards are likely to in turn reference optional  
mechanisms for key rotation and discovery, as well as reference  
different crypto schemes like HMAC or RSA.


There are already people in the identity community working on specs  
that are related to OAuth2, but which have value in other use- 
cases.  For example, there are people working on defining standards  
around token formats, signing blobs of different types (such as a  
token and/or HTTP request), key discovery/rotation, and consumer- 
key namespaces across vendors.  Dirk Balfanz from Google recently  
sent out updated drafts of some of those specs, and they also  
leverage specs that John Panzer from Google has worked on for Magic  
Signatures, as well as input from people in the community who are  
not at Google.


However even though Google is working on those specs, we still  
believe it is a mistake to delay the OAuth2 core spec standard to  
wait on broad agreement for a "signature proposal," just as it  
would be a mistake to delay the OAuth2 core spec to wait on the  
standards efforts around token formats, token signing, key  
discovery/rotation, consumer-key naming, etc.


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


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

Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

[Eran Hammer-Lahav]

Thanks Richard.

FWIW, RFC 5849 was stuck in IESG discuss until I the language regarding the use 
of HTTPS with plaintext secrets was changed from SHOULD to MUST. Before the 
change, the security consideration section clearly highlighted the danger in 
not using HTTPS. OAuth 2.0 adds support for short-lived tokens which addresses 
*some* of these concerns, but completely lacks any requirements for issuing 
short-lived bearer tokens, or provides any guidance on what short-lived is.

I am happy to include the signature scheme from 1.0a as-is, but I think we can 
easily simplify it, as draft -05 demonstrated using less than 4 pages. It can 
be made even simpler.

I think draft -05 went too far in terms of additional parameters for requesting 
tokens with secrets. Since the core spec lacks any form of discovery, I think 
servers should simply issue whatever token they deem appropriate to the client 
(bearer, with secret, etc.). Other extensions can define parameters to allow 
the client to ask, and the server to advertise whaich schemes are supported.

My approach is for the server to issue a token with two additional parameters: 
signature algorithm and secret. Based on that, the client will send requests 
with a few additional parameters (nonce, timestamp, signature - maybe combined 
into one).

If it wasn't clear, the reason why I am back at fighting for this after taking 
a break for a few months, is based on the recent positive experience from the 
Twitter migration. To me, it completely voids the arguments that normalization 
on the client side is too hard.

EHL


On 9/23/10 7:38 PM, "Richard Barnes"  wrote:

I also agree with the observation about consensus being based on individual 
voices.

I don't think it's accurate to say that signatures are a generic security 
mechanism.  As I would think we learned from OAuth 1.0[a], it can actually be 
pretty subtle to define how signatures are used in a given context.

I doubt that a spec that only includes a "bearer token" model will not have 
enough of a security story to get past SECDIR and IESG review, especially 
without some careful thinking about when TLS is required and how it is 
negotiated (for example, you may need something like HSTS [1]).

On the other hand, it seems like a sensible compromise approach to re-use the 
signature scheme from OAuth 1.0a.  If there is interest in some other type of 
signing scheme, then of course the cost of this approach is having some sort of 
versioning / negotiation for signature algorithms.  But this may already be 
necessary to distinguish between signed requests and bearer-token requests.

--Richard

[1] 




On Sep 23, 2010, at 9:30 PM, Dick Hardt wrote:

I agree with your point that consensus is based on individual voices.

I agree with Eric's points that signatures are a generic security mechanism and 
that signatures should be in a separate spec.

-- Dick


On 2010-09-23, at 6:11 PM, Eran Hammer-Lahav wrote:

It is pretty clear from the recent public response that a core specification 
without signatures is going to be viewed as weak and insecure. This has been my 
position for over a year, and if it wasn't clear, I am going to continue 
expressing it.

 We have enough interest to get a basic signature support in the core 
specification, one that is not driven by enterprise use cases, complex identity 
solutions, or large distributed systems. Given the recent Twitter migration to 
OAuth 1.0a proved that with a big enough carrot (or stick, depending on your 
view), developers figure it out. I believe that an OAuth 1.0a style signature 
can be easily developed and added to the core specification as an optional 
feature.

 This is not new. This was agreed upon at the Anaheim meeting. I took the 
signature language out of the draft in order to focus the discussion on the 
other components. Now that -10 is pretty solid (normative language-wise), it is 
time to bring it back in.

 Draft -11 will include a signature proposal, even if that means a short delay.

 The arguments about delaying the core spec are meritless, given that a growing 
number of companies are releasing OAuth 2.0 APIs using the latest stable draft. 
We can easily do a WGLC for the current stable components, and add signatures 
without changing those. This working group does not make technical and 
architectural decisions based on the timeline needs of any company. We do what 
is best for the web and we take as much time as necessary.

 As an aside, while companies can certainly express their corporate position on 
matters, this is a working group of individuals, and consensus is based solely 
on individual voices.

 EHL






 On 9/23/10 5:30 PM, "Eric Sachs"  > wrote:


Google wanted to re-state our long standing opinions on HTTP signature 
mechanisms in the OAuth2 spec.  The short version is that standards for signing 
parts of an HTTP request have value in use-cases other than OAuth

Re: [OAUTH-WG] Signatures spec proposal, take 2

[Richard L. Barnes]

Basically, this argument comes down to which validation pattern you  
prefer.


OPTION 1:
0. Input = object + signature
1. Verify match between object data and HTTP fields
2. Verify signature over the object

OPTION 2:
0. Input = signature
1. Construct object data from HTTP fields
2. Verify signature over the object

So the choice is between memcmp and memcpy :)

As Eran noted, there is some security advantage in option 2, since it  
forces the data in the signed object to correspond to the actual HTTP  
request instead of relying on the recipient to verify.  I would prefer  
that pattern, for that reason.


That's not to say that the JSON token proposal is without any  
utility.  For example, option 2 could take as input a JSON token with  
the 'data' element removed; the recipient would then reconstruct the  
'data' element from the HTTP request and verify the  token.


As an editorial note, it would be very helpful if the JSON token  
document could be made a little more stand-alone w.r.t. the Magic  
Signatures draft.  An example would also help, just to illustrate the  
overall structure of the token.


--Richard



On Sep 23, 2010, at 10:32 PM, Eran Hammer-Lahav wrote:

First, thanks for putting this together. It provides a pretty  
comprehensive story about the signed tokens proposal. I don’t have  
much to add at this point to the drafts.


My position, which I have expressed many times before about this  
approach is:


Any solution involving repeating the HTTP request elements in some  
sort of envelope will require validation .In this case, you need to  
define all the rules for validating the ‘audience’ parameter.


This approach makes it too tempting for server developers to ignore  
the HTTP request and only use the values of the ‘audience’ and  
‘method’ parameters. In order to validate those parameters, the  
server needs to perform some sort of normalization (which eventually  
leads to the same signature mismatch problems). Not looking at the  
HTTP request will lead to security problems because it will allow  
bypassing existing HTTP firewall rules which operate on the request  
URI and HTTP method.


As a matter of personal taste, this smells too much like SOAP. And  
that’s a really bad thing.


I am not in favor of any solution that replicates components of the  
HTTP request within the request (as is the case here). Recent  
experience shows that with a little help and good libraries,  
developers can figure out how to normalize and sign an HTTP request  
successfully, when motivated.


EHL


On 9/23/10 7:07 PM, "Dirk Balfanz"  wrote:



On Thu, Sep 23, 2010 at 6:51 PM, Eran Hammer-Lahav > wrote:
In part II, how is the signature bound to the HTTP request URI? I  
see the method and body, but not the request URI.


The request URI goes in the audience parameter that's defined in  
part I.


Dirk.


EHL



On 9/23/10 3:39 PM, "Dirk Balfanz" http://balf...@google.com 
> > wrote:


Hi guys,

sorry it took a while, but here is an updated proposal. It's still  
in three parts:


Part I is about "JSON Tokens" that can be used for all sorts of  
things, not just OAuth:

http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html

Part II is about how to embed an OAuth token and (some parts of) an  
HTTP request into a JSON Token:

http://balfanz.github.com/jsontoken-spec/draft-balfanz-signedoauth2-00.html

Part III is how to use signatures instead of client secrets for  
assertions in OAuth:

http://balfanz.github.com/jsontoken-spec/draft-balfanz-clientassertions-00.html

Diffs from the last specs are:

- JSON Tokens are now just a profile of Magic Signatures, which John  
Panzer has helpfully extended for this purpose
- There was a vulnerability to masquerading attacks in the last  
proposal, which is addressed in this proposal by adding a data_type  
parameter that is part of the signature, but _not_ part of the  
payload.
- no more support of X.509 certs - the only supported format for  
discovered public keys is now the Magic Key format. We'll give  
people tools (which are quite easy to write) to convert their self- 
signed or CA-issued certs to magic keys.

- The specs are now formatted as I-Ds.

Comments, please!

Dirk.




___
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] Basic signature support in the core specification

[William Mills]

+1

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Thursday, September 23, 2010 6:44 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Basic signature support in the core specification
>
> Since much of this recent debate was done off list, I'd like to ask
> people
> to simply express their support or objection to including a basic
> signature
> feature in the core spec, in line with the 1.0a signature approach.
>
> This is not a vote, just taking the temperature of the group.
>
> EHL
>
> ___
> 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