Subject: [OAUTH-WG] Basic signature support in the core specification

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 23 Sep 2010 18:43:35 -0700

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 24 Sep 2010 12:26:06 +0200

+1 for basic signature support

there is a need to protect end-users from token abuse by rogue resource 
servers (see 
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5, paragraph 
3). Signatures based on a token secret is one way to prevent this kind 
of attack.

Signature mechanisms aiming for other purposes (e.g. client 
authentication) should be defined as extensions in my opinion.

 >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).

+1

This is simple but sufficient. The authz server and resource server have 
a strong coupling anyway so the authz server should know what the 
resource server expects. Does this also mean the client MUST send signed 
requests if the authz server issued a token secret?

regards,
Torsten.

Am 24.09.2010 03:43, schrieb Eran Hammer-Lahav:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Bastian Hofmann <[email-masked]>
Date: Fri, 24 Sep 2010 13:22:08 +0200

+1

---

From: George Fletcher <[email-masked]>
Date: Fri, 24 Sep 2010 07:58:04 -0400

+1

I am agnostic as to whether this means we define the signatures within 
the spec or just reference/profile some other work. The fewer number of 
signature algorithms we have to implement the better:)

George

---

From: Justin Richer <[email-masked]>
Date: Fri, 24 Sep 2010 09:36:25 -0400

I would like to see the signatures stay in a separate spec, but to be
worked on and released along side of the core spec. 

In fact, I think that there's more than one kind of "signature" that can
be used with the OAuth token mechanisms. At IIW East, we walked through
several use cases that called for different kinds of signatures to
support them: signed tokens and signed requests. I have direct uses for
the signed request mechanism (a la OAuth 1.0, 2-legged and otherwise),
and I have seen others with compelling use cases for signed tokens.

 -- Justin

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 24 Sep 2010 12:51:22 -0400

I hope I am not causing the temperature of the group to rise dangerously
by "voting" in support (a.k.a. +1).

Igor

---

From: Eve Maler <[email-masked]>
Date: Fri, 24 Sep 2010 13:37:39 -0700

+1 for signature support in the core spec (which may look like normative pointers out to a separate spec module if it turns out there's wider usage for that module beyond OAuth).

	Eve

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

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: Justin Richer <[email-masked]>
Date: Fri, 24 Sep 2010 16:52:10 -0400

Perhaps this is picking nits but I want to clarify my opinion: I'm fine
if the core spec *mentions* signatures, I just don't want it to *define*
them. I'm perfectly happy with a section on "if you want to do signing,
here's a way to do signing", but I want that way to be defined and
described elsewhere. I think that the wide use of the "signed HTTP
request" pattern of 2-legged OAuth 1.0 has shown us that there is
utility to the signing capability outside of the token mechanism. I
could see people profiling OAuth 1.0 signing, Magic Signatures, JSON
Tokens, and maybe other approaches, all for use with OAuth2 tokens or
even otherwise-bare HTTP.

 -- Justin

---

From: "Doreswamy, Rangan" <[email-masked]>
Date: Fri, 24 Sep 2010 14:06:00 -0700

+1 for adding it in to the core spec..

Thanks,
RD
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eve Maler
Sent: Friday, September 24, 2010 1:38 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Basic signature support in the core
specification

+1 for signature support in the core spec (which may look like normative
pointers out to a separate spec module if it turns out there's wider
usage for that module beyond OAuth).

	Eve

---

From: John Panzer <[email-masked]>
Date: Fri, 24 Sep 2010 16:26:39 -0700

-1 on requiring it to be part of core OAuth2.  Reasoning: It won't be a MUST
or even SHOULD requirement for either client or server, so adding it later
does not affect interop.  The actual schedule to finalize the signature
mechanism should not be affected either way -- it's fine for a WG to produce
2 or more RFCs if that's the right thing to do.  (If there were consensus
today on what exactly the signing mechanism should be I'd think differently,
but I don't believe there is.)

Caveat:  If there were consensus that OAuth 2 should simply adopt the OAuth
1.0a signature mechanism today, I'd be okay with that, just because there is
some proven code out there.

This is of course a trade-off.  My bias:  I really want us to stabilize what
has been spec'd so far and move forward with that while additional work
happens.  There are already multiple mutually implementations of "OAuth2"
floating around and I'd rather resolve that quickly.
--
John Panzer / Google
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

---

From: David Recordon <[email-masked]>
Date: Fri, 24 Sep 2010 16:54:03 -0700

+1 on core

---

From: Dick Hardt <[email-masked]>
Date: Fri, 24 Sep 2010 17:20:03 -0700

That's a confusing answer Eve. Is it in the spec or pointed to from the spec? 

I think there is consensus that there are enough use cases that signatures need to be spec'ed -- the question is if the signature spec is in core or a separate spec.

For people that don't need signatures, having them separate keeps the core spec simpler. Having a separate spec enables other groups to reuse the signature mechanism without confusing their readers with the rest of the OAuth spec.

---

From: Dick Hardt <[email-masked]>
Date: Fri, 24 Sep 2010 17:21:44 -0700

-1 in core

+1 to being referenced in core and being a separate document

---

From: Nat <[email-masked]>
Date: Sat, 25 Sep 2010 09:35:39 +0900

+1 on referencing separate spec from the core. 
-1 for actually defining the sig inside the core. 

=nat @ Tokyo via iPhone

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 24 Sep 2010 19:22:57 -0700

OAuth 2.0 is far from being published as an RFC. I estimate it is at least 6 months away from reaching final IESG approval, if not a year. This is mostly due to a significant effort needed in writing and reviewing the security considerations section which so far has received no attention. We can easily lock down the bearer token portions and continue working on the spec. The argument that it needs to be published as an RFC for companies to deploy is both irrelevant and untrue. Facebook and Salesforce are two examples.

If your entire argument is that waiting for a signature will delay core, I am happy to promise that if the rest of the specification is done, and signatures are the only thing holding it back from publication, that we can take them out and publish.

My main issue with a separate specification is that is sends a clear (and misguided) message that signatures are some advance and complex thing most developers should ignore. It promoted bearer tokens to be the preferred implementation (in practice, an implied MUST) which will render any signature work pointless (an afterthought MAY). By putting it in the same specification (and I have clearly demonstrated that this can be done in under 4 pages) we give developers a complete picture and let them choose. We also get to call out the shortcomings of using bearer tokens and directly point to one possible alternative.

It is ridiculous how much time those opposed to signatures have wasted by demanding justification, proposing complex replacements, or just intentionally derailed any effort to come up with a simple signature solution.

If we can't quickly agree on a new signature, I am going to take 1.0a and paste it into the specification. That will be sad and pathetic, and will ignore our responsibility to move the web forward, but its light years better than a specification with only bearer tokens.

We have to find a quick way to compromise, or we will find ourselves with plenty more issues to resolve. I know a few people (myself included) who dropped their opposition to bearer tokens (especially without requiring HTTPS) that will be inclined to bring this up again and reopen the topic. It seems those who promote bearer tokens as the core 2.0 protocol got everything they wanted but have not given an inch so far.

EHL

On 9/24/10 4:26 PM, "John Panzer" <[email-masked]> wrote:

-1 on requiring it to be part of core OAuth2.  Reasoning: It won't be a MUST or even SHOULD requirement for either client or server, so adding it later does not affect interop.  The actual schedule to finalize the signature mechanism should not be affected either way -- it's fine for a WG to produce 2 or more RFCs if that's the right thing to do.  (If there were consensus today on what exactly the signing mechanism should be I'd think differently, but I don't believe there is.)

Caveat:  If there were consensus that OAuth 2 should simply adopt the OAuth 1.0a signature mechanism today, I'd be okay with that, just because there is some proven code out there.

This is of course a trade-off.  My bias:  I really want us to stabilize what has been spec'd so far and move forward with that while additional work happens.  There are already multiple mutually implementations of "OAuth2" floating around and I'd rather resolve that quickly.
--
John Panzer / Google
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/>  / @jpanzer

On Thu, Sep 23, 2010 at 6:43 PM, Eran Hammer-Lahav <[email-masked]> wrote:
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.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 24 Sep 2010 19:23:31 -0700

Most developers don't know if they need signatures! By putting them elsewhere we will be promoting the bearer token approve as the default choice and that's unacceptable to me. It is promoting a specific security compromise (for developer ease) that is far from industry consensus.

I can make the same arguments about assertions. Or any single profile. Or any client credentials type. The bits that are in are based solely on a team effort in trying to accommodate as many people as possible. Seems like those opposed signatures got everything they want, don't really care about others, and are ready to call it a day.

EHL

On 9/24/10 5:20 PM, "Dick Hardt" <[email-masked]> wrote:

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 24 Sep 2010 19:24:54 -0700

I'm happy to do that. But I will be breaking the spec into more than two parts. Basically, I will be creating a version that does not force anyone to read anything they might not care about. Clearly, we shouldn't based editorial decisions on what you want to read :-)

EHL

On 9/24/10 5:21 PM, "Dick Hardt" <[email-masked]> wrote:

-1 in core

---

From: Dick Hardt <[email-masked]>
Date: Fri, 24 Sep 2010 22:39:26 -0700

wrt. developers knowing what they need => I think the AS / PR will tell developers if they need to use signatures, or if they need to use HTTPS, or if they need to use assertions. 

Sorry for including more than one topic in my email :: my main point was that I was confused by what Eve was proposing.

-- Dick

On 2010-09-24, at 7:23 PM, Eran Hammer-Lahav wrote:

> Most developers don’t know if they need signatures! By putting them elsewhere we will be promoting the bearer token approve as the default choice and that’s unacceptable to me. It is promoting a specific security compromise (for developer ease) that is far from industry consensus.
> 
> I can make the same arguments about assertions. Or any single profile. Or any client credentials type. The bits that are in are based solely on a team effort in trying to accommodate as many people as possible. Seems like those opposed signatures got everything they want, don’t really care about others, and are ready to call it a day.
> 
> EHL
> 
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 24 Sep 2010 22:43:02 -0700

I don't follow your logic ... or perhaps I don't see why the spec needs to be written in more than two parts.

For example, the current spec does not specify the format of the token -- which keeps it simpler and straight forward. There are separate draft specs for standardizing the token. Similarly, I think the spec could be written to not include signatures, and put signatures into a different, reusable spec. If you would like help with that organization, I'll volunteer. :)

-- Dick

On 2010-09-24, at 7:24 PM, Eran Hammer-Lahav wrote:

> I’m happy to do that. But I will be breaking the spec into more than two parts. Basically, I will be creating a version that does not force anyone to read anything they might not care about. Clearly, we shouldn’t based editorial decisions on what you want to read :-)
> 
> EHL
> 
>

---

From: Mark Mcgloin <[email-masked]>
Date: Sat, 25 Sep 2010 09:57:07 +0100

+1 to having it in the core spec. I don't see how an optional section in
the spec will cause any confusion

+1 to John's suggestion below of starting with the OAuth 1.0a signature
mechanism. Why not put it in the spec and see what breaks or no longer
holds true

Mark McGloin

John Panzer wrote on 25/09/2010 00:26

-1 on requiring it to be part of core OAuth2.  Reasoning: It won't be a
MUST or even SHOULD requirement for either client or server, so adding it
later does not affect interop.  The actual schedule to finalize the
signature mechanism should not be affected either way -- it's fine for a WG
to produce 2 or more RFCs if that's the right thing to do.  (If there were
consensus today on what exactly the signing mechanism should be I'd think
differently, but I don't believe there is.)

Caveat:  If there were consensus that OAuth 2 should simply adopt the OAuth
1.0a signature mechanism today, I'd be okay with that, just because there
is some proven code out there.

This is of course a trade-off.  My bias:  I really want us to stabilize
what has been spec'd so far and move forward with that while additional
work happens.  There are already multiple mutually implementations of
"OAuth2" floating around and I'd rather resolve that quickly.
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

On Thu, Sep 23, 2010 at 6:43 PM, Eran Hammer-Lahav <[email-masked]>
wrote:
  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.

  EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 25 Sep 2010 13:10:25 +0200

Am 25.09.2010 04:22, schrieb Eran Hammer-Lahav:
> OAuth 2.0 is far from being published as an RFC. I estimate it is at 
> least 6 months away from reaching final IESG approval, if not a year. 
> This is mostly due to a significant effort needed in writing and 
> reviewing the security considerations section which so far has 
> received no attention. 

FYI: Mark McGloin and me started to work on the security considerations. 
We will announce once we have collected and written down enough to share 
with the WG.

One thing we most likely will come up with is the question how to 
prevent token phishing and abuse by resource servers.

We already had a discussion about such threat scenarios in the WG when 
James H. Manger brought up his sites proposal 
(http://www.ietf.org/mail-archive/web/oauth/current/msg02343.html, 
detailed threat description in 
http://www.ietf.org/mail-archive/web/oauth/current/msg02366.html). Up to 
now, we don't have a solution in the draft.

A simple signature mechanism just for this purpose (not for client 
authentication, message integrity nor token/assertion integrity 
protection) is one option, James's proposal would be another. Since a 
lot of running code is out there for OAuth 1.0a signature, I'm fine with 
John's proposal. I would just recommend to drop the client secret from 
the signature calculation because not all clients will have a secret and 
making client secrets avalailable to resource servers causes other 
(scalability and security) problems. Using such a mechanism in 
combination with HTTPS should suffice.

In my perception from IETF 78, a lot of IETF people assess OAuth to fall 
back behind established IETF authentication & authorization protocols 
like Kerberos in terms of security. As far as I remember people were 
nearly shocked at the WG meeting to read the transmission of tokens (== 
credentials) over a secure channel is just a SHOULD and not a MUST. 
Moreover, the potential for token abuse became apparent instantely. In 
my opinion, we should work towards security improvements otherwise 
approval by IETF will be very hard.

regards,
Torsten.

> We can easily lock down the bearer token portions and continue working 
> on the spec. The argument that it needs to be published as an RFC for 
> companies to deploy is both irrelevant and untrue. Facebook and 
> Salesforce are two examples.
>
> If your entire argument is that waiting for a signature will delay 
> core, I am happy to promise that if the rest of the specification is 
> done, and signatures are the only thing holding it back from 
> publication, that we can take them out and publish.
>
> My main issue with a separate specification is that is sends a clear 
> (and misguided) message that signatures are some advance and complex 
> thing most developers should ignore. It promoted bearer tokens to be 
> the preferred implementation (in practice, an implied MUST) which will 
> render any signature work pointless (an afterthought MAY). By putting 
> it in the same specification (and I have clearly demonstrated that 
> this can be done in under 4 pages) we give developers a complete 
> picture and let them choose. We also get to call out the shortcomings 
> of using bearer tokens and directly point to one possible alternative.
>
> It is ridiculous how much time those opposed to signatures have wasted 
> by demanding justification, proposing complex replacements, or just 
> intentionally derailed any effort to come up with a simple signature 
> solution.
>
> If we can't quickly agree on a new signature, I am going to take 1.0a 
> and paste it into the specification. That will be sad and pathetic, 
> and will ignore our responsibility to move the web forward, but its 
> light years better than a specification with only bearer tokens.
>
> We have to find a quick way to compromise, or we will find ourselves 
> with plenty more issues to resolve. I know a few people (myself 
> included) who dropped their opposition to bearer tokens (especially 
> without requiring HTTPS) that will be inclined to bring this up again 
> and reopen the topic. It seems those who promote bearer tokens as the 
> core 2.0 protocol got everything they wanted but have not given an 
> inch so far.
>
> EHL
>
>
>     -1 on requiring it to be part of core OAuth2.  Reasoning: It won't
>     be a MUST or even SHOULD requirement for either client or server,
>     so adding it later does not affect interop.  The actual schedule
>     to finalize the signature mechanism should not be affected either
>     way -- it's fine for a WG to produce 2 or more RFCs if that's the
>     right thing to do.  (If there were consensus today on what exactly
>     the signing mechanism should be I'd think differently, but I don't
>     believe there is.)
>
>     Caveat:  If there were consensus that OAuth 2 should simply adopt
>     the OAuth 1.0a signature mechanism today, I'd be okay with that,
>     just because there is some proven code out there.
>
>     This is of course a trade-off.  My bias:  I really want us to
>     stabilize what has been spec'd so far and move forward with that
>     while additional work happens.  There are already multiple
>     mutually implementations of "OAuth2" floating around and I'd
>     rather resolve that quickly.
>     --
>     John Panzer / Google
>     [email-masked] / abstractioneer.org
>     <http://www.abstractioneer.org/>  / @jpanzer
>
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 25 Sep 2010 07:52:38 -0700

I was talking about AS / PR developers.

EHL

On 9/24/10 10:39 PM, "Dick Hardt" <[email-masked]> wrote:

-- Dick

EHL

On 9/24/10 5:20 PM, "Dick Hardt" <[email-masked] <x-msg://12/[email-masked]> > wrote:

On 2010-09-24, at 1:37 PM, Eve Maler wrote:

>> [email-masked] <x-msg://12/[email-masked]>
> [email-masked] <x-msg://12/[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 25 Sep 2010 07:54:30 -0700

My logic is that your suggested organization is based on your personal preferences and what you consider core. If I applied my personal preference, half of core would be elsewhere. My point is that deciding signatures is the part belonging elsewhere is completely subjective to how important one think it is.

EHL

On 9/24/10 10:43 PM, "Dick Hardt" <[email-masked]> wrote:

-- Dick

EHL

On 9/24/10 5:21 PM, "Dick Hardt" <[email-masked] <x-msg://14/[email-masked]> > wrote:

-1 in core

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

> [email-masked] <x-msg://14/[email-masked]>

---

From: Dick Hardt <[email-masked]>
Date: Sat, 25 Sep 2010 12:25:12 -0700

To be clear, I think signatures are important, and I think that standardizing them would be really useful. One of the early complaints about OAuth 1.0 was that the signature mechanism was different than the OpenID mechanism. Having a standard signature mechanism in this space seems like a good thing. Having a signature mechanism be an optional part of the OAuth spec makes them less appealing to others.

I also think that standard tokens are really useful, and that they would be useful in other places besides OAuth, which is why they are in a different spec.

---

From: Eve Maler <[email-masked]>
Date: Sat, 25 Sep 2010 19:52:03 -0700

It seems like you figured it out pretty quickly, given the message you sent immediately after. :-)

Referencing another spec from the core spec using normative text is effectively "including it by reference". I meant that I'm sympathetic (+1) to signaling in core OAuth that signatures are to be considered an integral part of it, and that if it makes sense to do so by pointing to a spec module that is pointable-to by other specs that are not OAuth, that's fine (call it a soft -1 to including the signature details directly in the core OAuth spec).

	Eve

---

From: Dick Hardt <[email-masked]>
Date: Sun, 26 Sep 2010 08:31:44 -0700

> Referencing another spec from the core spec using normative text is effectively "including it by reference". I meant that I'm sympathetic (+1) to signaling in core OAuth that signatures are to be c…

thanks for clarifying your view since it seemed you had +1 to having details in OAuth and +1 to referencing

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 27 Sep 2010 11:12:36 +1000

-1 to including a signature mechanism in OAuth2 core

+1 to OAuth2 being clear about how it can deliver a secret key (and algorithm id etc) that can be used by a signature mechanism

Firstly -- a mechanism to sign HTTP requests would be great, but should not be dependent on methods for users to delegate authority to apps, or on methods for apps to get temporary, less-privileged credentials. That is, don't make it OAuth-specific.
Defining a request signing mechanism in OAuth2 core will cripple it with OAuth-specific quirks. The OAuth1 signing mechanism, for instance: uses names with "oauth_" prefixes; uses 2 keys (an apps long-term key, and the delegation-specific token key) whereas generic signing mechanisms invariable work with a single signing key; and overloads a single HTTP authentication scheme name with multiple purposes (indicating a server supports delegation, and conveying a request signature).

Secondly -- there isn't just one sensible signing mechanism, so how do we pick which one is specified in OAuth2 core. An enveloping-style signature (eg magic signatures?); an OAuth1-style signature using 2 keys; a signature covering HTTP method/URI/body but not other headers; a signature covering any HTTP headers; a signature that can be encoded in a URI; a signature that also works on non-HTTP systems; a signature scheme that is efficient when the client app already has its own long-term public/private key pair...

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 26 Sep 2010 23:02:54 -0700

Clearly, this group is making choices based on the kind of applications using OAuth 1.0 today. The decision to focus on bearer tokens came from specific experiences and types of consumer web services.

I'm all for a simple and generic way to issue a token with additional attributes such as a secret, required algorithm, etc. But main objection is to the publication of a standard that promotes bearer token as its "purest" form, and moves something that I consider a core security component to somewhere else.

I completely agree that we are going to have more than one signature mechanism. Any attempt to come up with some unified and generically useful method is idiotic. We have very different views, approaches, and needs.

However, I'd like us to pick one that is simple and in line with the 1.0 approach - this is very much in line with the market expectation, and the expectations of most people who joined this group to work on the next version of OAuth. My plan from the time I brought OAuth to the IETF and worked to create this working group was to build directly on top of the 1.0 signature method. We don't need to go far, just clean it up a bit to make it simpler and reflect the improve environment OAuth operates in (three years later).

IOW, instead of wasting another 6 months of this pointless debate regarding signatures, I would like to see us take the 1.0 HMAC method, have a focused discussion about how it can be made better without changing its architecture (basically, just simplifying the base string), and including that with a clear method for extensions. In addition, I would hope that Dirk's proposal moves forward and reaches a stable state alongside core, so that it too, can be referenced.

If we cannot agree on one (and we cannot), I want us to provide options. What I absolutely object to is presenting a specification that to a new reader will read as if bearer tokens are the default way to go. OAuth 2.0 core today reads like a complete protocol and that's my problem.

EHL

> Of Manger, James H
> Sent: Sunday, September 26, 2010 6:13 PM
> To: OAuth WG
> Subject: Re: [OAUTH-WG] Basic signature support in the core specification
> 
> +1 to OAuth2 being clear about how it can deliver a secret key (and algorithm
> id etc) that can be used by a signature mechanism
> 
> Firstly -- a mechanism to sign HTTP requests would be great, but should not
> be dependent on methods for users to delegate authority to apps, or on
> methods for apps to get temporary, less-privileged credentials. That is, don't
> make it OAuth-specific.
> Defining a request signing mechanism in OAuth2 core will cripple it with
> OAuth-specific quirks. The OAuth1 signing mechanism, for instance: uses
> names with "oauth_" prefixes; uses 2 keys (an apps long-term key, and the
> delegation-specific token key) whereas generic signing mechanisms
> invariable work with a single signing key; and overloads a single HTTP
> authentication scheme name with multiple purposes (indicating a server
> supports delegation, and conveying a request signature).
> 
> Secondly -- there isn't just one sensible signing mechanism, so how do we
> pick which one is specified in OAuth2 core. An enveloping-style signature (eg
> magic signatures?); an OAuth1-style signature using 2 keys; a signature
> covering HTTP method/URI/body but not other headers; a signature covering
> any HTTP headers; a signature that can be encoded in a URI; a signature that
> also works on non-HTTP systems; a signature scheme that is efficient when
> the client app already has its own long-term public/private key pair...
> 
> 
> --
> James Manger

---

From: Dick Hardt <[email-masked]>
Date: Sun, 26 Sep 2010 23:20:42 -0700

> Clearly, this group is making choices based on the kind of applications using OAuth 1.0 today. The decision to focus on bearer tokens came from specific experiences and types of consumer web servic…

Any other applications are hypothetical.

> I'm all for a simple and generic way to issue a token with additional attributes such as a secret, required algorithm, etc. But main objection is to the publication of a standard that promotes bear…

It is only a core security component in some use cases.

>  What I absolutely object to is presenting a specification that to a new reader will read as if bearer tokens are the default way to go. OAuth 2.0 core today reads like a complete protocol and that's my problem.

It is a complete protocol for many existing use cases. For those use cases where it is not, you can call require signatures and point people to the signature spec, just like the use of bearer tokens points people to the TLS specs.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 26 Sep 2010 23:37:33 -0700

> From: Dick Hardt [mailto:[email-masked]]
> Sent: Sunday, September 26, 2010 11:21 PM

> >  What I absolutely object to is presenting a specification that to a new
> reader will read as if bearer tokens are the default way to go. OAuth 2.0 core
> today reads like a complete protocol and that's my problem.
> 
> It is a complete protocol for many existing use cases.

That's clearly a matter of personal opinion :-) and why we have been arguing about this for over a year.

> For those use cases
> where it is not, you can call require signatures and point people to the
> signature spec, just like the use of bearer tokens points people to the TLS
> specs.

According to Ben Laurie [1] and Ben Adida [2], a simple reference to TLS is a recipe for disaster. People tend to implement TLS incorrectly on the client side which voids many of the important protections it is meant to provide.

As the editor, I am having a hard time consolidating your view which treats readers as security experts, capable of making educated decisions about the protocol, and the demands from others that the specification should be completely accessible to any developer (especially those with no security background) and read like a tutorial on OAuth.

If we want to keep the full range, we need to clearly express it, including highlighting the significant shortcomings of bearer tokens, the known TLS deployment issues, and the value in whatever signature proposals we have ready to reference or include.

Standards are meant to improve interoperability, but also security. This is why any IETF charter dealing with an existing technology states that the working group may break compatibility if it has interop or security reasons to do so. We are doing fine on interop, but doing pretty badly on security.

EHL

[1] http://www.links.org/?p=846 
[2] http://benlog.com/articles/2009/12/22/its-a-wrap/

---

From: John Panzer <[email-masked]>
Date: Mon, 27 Sep 2010 00:01:15 -0700

On Sun, Sep 26, 2010 at 11:37 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> According to Ben Laurie [1] and Ben Adida [2], a simple reference to TLS is
> a recipe for disaster.

Actually in [1], Ben Laurie does not say that a simple reference to TLS is a
recipe for disaster.  (Go read it.)  In fact his first point is that you
need a well-define threat model before you can talk sensibly about any of
this; I would really like us to do that in this case too.

> People tend to implement TLS incorrectly on the client side which voids
> many of the important protections it is meant to provide.
>

The bits they tend to implement incorrectly (specifically, things like
checking for certificate revocations) seem to me to be very general and
exactly the kinds of things one needs in order to implement _any_ protection
against the endpoint impersonation you are worried about.  Why would they be
more likely to get it right for a new protocol than for an existing one?

>
> As the editor, I am having a hard time consolidating your view which treats
> readers as security experts, capable of making educated decisions about the
> protocol, and the demands from others that the specification should be
> completely accessible to any developer (especially those with no security
> background) and read like a tutorial on OAuth.
>
> If we want to keep the full range, we need to clearly express it, including
> highlighting the significant shortcomings of bearer tokens, the known TLS
> deployment issues, and the value in whatever signature proposals we have
> ready to reference or include.
>
> Standards are meant to improve interoperability, but also security. This is
> why any IETF charter dealing with an existing technology states that the
> working group may break compatibility if it has interop or security reasons
> to do so. We are doing fine on interop, but doing pretty badly on security.
>
> EHL
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 27 Sep 2010 06:30:54 -0700

I'll echo John's comments and remind you that Micrsoft, Yahoo! and Google security experts with plenty of real world experience worked on WRAP which is OAuth bearer tokens.

Microsoft, Google, Salesforce, Facebook and others have deployed bearer token OAuth in production after internal security reviews. I don't think that is a personal opinion, that is fact. 

wrt. another comment you had about security considerations, Brian Eaton did write up a bunch of security considerations for WRAP.

On 2010-09-27, at 12:01 AM, John Panzer wrote:

> On Sun, Sep 26, 2010 at 11:37 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> 
> 
> According to Ben Laurie [1] and Ben Adida [2], a simple reference to TLS is a recipe for disaster.
> 
> Actually in [1], Ben Laurie does not say that a simple reference to TLS is a recipe for disaster.  (Go read it.)  In fact his first point is that you need a well-define threat model before you can talk sensibly about any of this; I would really like us to do that in this case too.
>  
> People tend to implement TLS incorrectly on the client side which voids many of the important protections it is meant to provide.
> 
> The bits they tend to implement incorrectly (specifically, things like checking for certificate revocations) seem to me to be very general and exactly the kinds of things one needs in order to implement _any_ protection against the endpoint impersonation you are worried about.  Why would they be more likely to get it right for a new protocol than for an existing one?
>  
>

---

From: Mark Mcgloin <[email-masked]>
Date: Mon, 27 Sep 2010 14:45:00 +0100

I have gone through Brian's wrap security considerations and will
incorporate them into the security considerations for OAuth 2 that Torsten
and I will compile. We can run it past Brian too

http://trac.tools.ietf.org/wg/oauth/trac/raw-attachment/wiki/SecurityConsiderations/OAuthWRAP2.0SecurityConsiderations.pdf

Regards
Mark McGloin

Dick Hardt wrote on 27/09/2010 14:30

> wrt. another comment you had about security considerations, Brian Eaton
did write up a bunch of security considerations for WRAP.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 27 Sep 2010 08:35:45 -0700

This is a stupid discussion. We have been talking past each other (the working group) for over a year. We are not likely to convince either side that bearer tokens are bad or good idea.

All these experts reviewed WRAP in the strict context of their own environment, with existing protocols and other weaknesses. Other and I are reviewing it in the wider context of what is good for the web, and am much less concerned about complexity. IOW, I don't believe that in this case WRAP made the right choice between developer ease and security.

This is also exactly the problem with the current specification. New readers are more likely to assume that what is good for these big companies is also good for them, without making their own threat model analysis. How would they reach any other conclusion when the specification doesn't offer a complete alternative?

We should focus on finding a compromise everyone can live with, since clearly debating the two sides has produced nothing. I think positioning bearer tokens as the primary mechanism, but including a signature alternative in the same specification is a reasonable compromise. Bearer token fans get the spotlight, while those looking for a signature (providing the same protections as 1.0a HMAC-SHA-1) get some algorithm included.

We need to find a way to give each side something to live with.

EHL

From: Dick Hardt [mailto:[email-masked]]
Sent: Monday, September 27, 2010 6:31 AM
To: John Panzer; Eran Hammer-Lahav
Cc: OAuth WG; Ben Laurie
Subject: Re: [OAUTH-WG] Basic signature support in the core specification

On Sun, Sep 26, 2010 at 11:37 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:

> From: Dick Hardt [mailto:[email-masked]<mailto:[email-masked]>]

EHL

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Mon, 27 Sep 2010 08:55:47 -0700

On 2010-09-27, at 8:35 AM, Eran Hammer-Lahav wrote:

> This is a stupid discussion.

I don't find this comment assists in finding a compromise, and a surprising comment from someone who has stated they don't have firm beliefs in what the spec does -- just wants to edit. You seem to have very strong views for an editor.

> We have been talking past each other (the working group) for over a year. We are not likely to convince either side that bearer tokens are bad or good idea.

Clearly they are a good idea for many use cases.

>  
> All these experts reviewed WRAP in the strict context of their own environment, with existing protocols and other weaknesses. Other and I are reviewing it in the wider context of what is good for the web, and am much less concerned about complexity. IOW, I don’t believe that in this case WRAP made the right choice between developer ease and security.

Your opinion :: heavily outweighed by real world implementation. 

>  
> This is also exactly the problem with the current specification. New readers are more likely to assume that what is good for these big companies is also good for them, without making their own threat model analysis. How would they reach any other conclusion when the specification doesn’t offer a complete alternative?

As stated, the spec should state when signing the request should (MUST?) be done and refer to the spec that defines how to sign. This enables the signing mechanism to easily used by others as well. I don't see why this does not meet your requirements.

> We should focus on finding a compromise everyone can live with, since clearly debating the two sides has produced nothing. I think positioning bearer tokens as the primary mechanism, but including…

See my other message.

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 27 Sep 2010 12:42:22 -0400

I think Torsten's previous comment explains it well: We cannot expect 
approval of the core, if security is not sufficiently addressed. I also 
agree that it cannot be addressed without the signature mechanism 
clearly specified. Therefore, if anything is going to delay the core, it 
is the absence of the signature specification. A dangling reference to 
work in progress won't help; the referred spec must be there.

But if both the OAuth signatures and the OAuth core specifications are 
complete and going for approval at the same time, why not actually have 
them in the same spec, especially given that we experts who have agreed 
working on this and ARE working on this?

Igor

Eve Maler wrote:
> Referencing another spec from the core spec using normative text is 
> effectively "including it by reference". I meant that I'm sympathetic 
> (+1) to signaling in core OAuth that signatures are to be considered 
> an integral part of it, and that if it makes sense to do so by 
> pointing to a spec module that is pointable-to by other specs that are 
> not OAuth, that's fine (call it a soft -1 to including the signature 
> details directly in the core OAuth spec).
>
> Eve
>
>> wrt. developers knowing what they need => I think the AS / PR will 
>> tell developers if they need to use signatures, or if they need to 
>> use HTTPS, or if they need to use assertions. 
>>
>> Sorry for including more than one topic in my email :: my main point 
>> was that I was confused by what Eve was proposing.
>>
>> -- Dick
>>
>>
>>> Most developers don’t know if they need signatures! By putting them 
>>> elsewhere we will be promoting the bearer token approve as the 
>>> default choice and that’s unacceptable to me. It is promoting a 
>>> specific security compromise (for developer ease) that is far from 
>>> industry consensus.
>>>
>>> I can make the same arguments about assertions. Or any single 
>>> profile. Or any client credentials type. The bits that are in are 
>>> based solely on a team effort in trying to accommodate as many 
>>> people as possible. Seems like those opposed signatures got 
>>> everything they want, don’t really care about others, and are ready 
>>> to call it a day.
>>>
>>> EHL
>>>
>>>
>>> On 9/24/10 5:20 PM, "Dick Hardt" <[email-masked] 
>>> <x-msg://12/[email-masked]>> wrote:
>>>
>>>     I think there is consensus that there are enough use cases that
>>>     signatures need to be spec'ed -- the question is if the
>>>     signature spec is in core or a separate spec.
>>>
>>>     For people that don't need signatures, having them separate
>>>     keeps the core spec simpler. Having a separate spec enables
>>>     other groups to reuse the signature mechanism without confusing
>>>     their readers with the rest of the OAuth spec.
>>>
>>>     > +1 for signature support in the core spec (which may look like
>>>     normative pointers out to a separate spec module if it turns out
>>>     there's wider usage for that module beyond OAuth).
>>>     >
>>>     >       Eve
>>>     >
> ------------------------------------------------------------------------
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 27 Sep 2010 09:55:59 -0700

Well said.

> Of Igor Faynberg
> Sent: Monday, September 27, 2010 9:42 AM
> To: Eve Maler
> Cc: OAuth WG
> approval of the core, if security is not sufficiently addressed. I also agree that
> it cannot be addressed without the signature mechanism clearly specified.
> Therefore, if anything is going to delay the core, it is the absence of the
> signature specification. A dangling reference to work in progress won't help;
> the referred spec must be there.
> 
> >>> Most developers don't know if they need signatures! By putting them
> >>> default choice and that's unacceptable to me. It is promoting a
> >>> everything they want, don't really care about others, and are ready
> >>> to call it a day.
> >>>
> >>> EHL
> >>>
> >>>

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 27 Sep 2010 13:01:34 -0400

I mistyped, and just noticed that it looked strange.  I meant to type:
Igor Faynberg wrote:
> ...
> complete and going for approval at the same time, why not actually 
> have them in the same spec, especially given that THE (not "we") 
> experts who have agreed working on this and ARE working on this?
>
> Igor
>
>
>
>>

---

From: William Mills <[email-masked]>
Date: Mon, 27 Sep 2010 10:08:40 -0700

Bearer tokens are appropriate for some use cases but not all, signed requests are appropriate for a different (intersecting?) set.  Both have use cases where they are not ideal or appropriate.    We should address both in the core spec,

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Monday, September 27, 2010 8:36 AM
To: Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Basic signature support in the core specification

EHL

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 27 Sep 2010 17:11:09 +0000

What is needed is needed is the security considerations section complete, I don't think that the signature specification has to be in the core to be complete, there are previsions to use SSL, if one needs to go beyond this then a reference to the signature specification would be in the security considerations section. The separation allows for an OAuth independent solution that would/could cover message and token encryption and signing. If signature is going to be an extension point why have any in the core? Already we would have questions from our customers on the use of HMAC-SHA1. According to Hannes the security considerations section is underway and will explain what signatures provide and what they do not provide and let the implementer choose what scenarios they are implementing for and the risk factors of those scenarios and if signatures are needed or just SSL.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Faynberg
Sent: Monday, September 27, 2010 9:42 AM
To: Eve Maler
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Basic signature support in the core specification

I think Torsten's previous comment explains it well: We cannot expect approval of the core, if security is not sufficiently addressed. I also agree that it cannot be addressed without the signature mechanism clearly specified. Therefore, if anything is going to delay the core, it is the absence of the signature specification. A dangling reference to work in progress won't help; the referred spec must be there.

But if both the OAuth signatures and the OAuth core specifications are complete and going for approval at the same time, why not actually have them in the same spec, especially given that we experts who have agreed working on this and ARE working on this?

Igor

---

From: Dick Hardt <[email-masked]>
Date: Mon, 27 Sep 2010 10:48:38 -0700

Myself and others feel that a spec for how to sign a request would be useful for other specifications. As I noted in a previous email, there was dismay when the signing of an OpenID message was very similar, but different than the signing in OAuth 1.0A. 

Signing messages was a huge stumbling block for OAuth 1.0A deployment. Having a more general signing specification that leads to generic libraries for signing and verifying would be a GOOD THING IMHO.

To be clear, I am not saying we should ignore signing, I see that it can be complex, particularly when you start looking at key discovery and multi algorithm support. I think it would be better to do it right in a spec rather than just including the OAUth 1.0A algorithm and it being cumbersome to deal with key management and alternative algorithm support.

On 2010-09-27, at 10:01 AM, Igor Faynberg wrote:

>> But if both the OAuth signatures and the OAuth core specifications are complete and going for approval at the same time, why not actually have them in the same spec, especially given that THE (not "we") experts who have agreed working on this and ARE working on this?
>> 
>> Igor
>> 
>> 
>> 
>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 27 Sep 2010 20:25:38 +0200

Am 27.09.2010 19:11, schrieb Anthony Nadalin:
> What is needed is needed is the security considerations section complete, I don't think that the signature specification has to be in the core to be complete, there are previsions to use SSL, if one needs to go beyond this then a reference to the signature specification would be in the security considerations section. The separation allows for an OAuth independent solution that would/could cover message and token encryption and signing. If signature is going to be an extension point

I don't understand why signing tokens and signing message shall be 
solved with the same solution.

In my opinion, tokens are opaque to any client and are just passed 
through as an uninterpreted string from authorization server (AS) to the 
resource server (RS) via the client. So the OAuth spec does not 
necessarily have to standardize their format (incl. signatures) in order 
to facilitate protocol interoperability. AS and RS just have to use the 
same format. Since both have a thight relationship that should not be a 
problem. If one like it can use an existing formats like SAML assertions 
or SWT.

That's completely different from message signing. Here all parties are 
involved. So any client accessing a pair of AS and RS has to know how to 
sign a message in order to prove legitimate token ownership and/or 
protect the message from modifications.

regards,
Torsten.

> why have any in the core? Already we would have questions from our customers on the use of HMAC-SHA1. According to Hannes the security considerations section is underway and will explain what signatures provide and what they do not provide and let the implementer choose what scenarios they are implementing for and the risk factors of those scenarios and if signatures are needed or just SSL.
>
>>>> On 9/24/10 5:20 PM, "Dick Hardt"<[email-masked]
>>>>      >>  [email-masked]<x-msg://12/[email-masked]>
>>>>      >  [email-masked]<x-msg://12/[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Mon, 27 Sep 2010 15:03:49 -0400

Arguments like this are why I have been advocating for separating the
"developers guide" from the "protocol spec" for a while now. I believe
that they support two different audiences. 

A developers' guide then has the option of combining multiple specs,
selecting profiles of those specs, and laying out exactly what's
happening at each step for people to follow. 

 -- Justin

On Mon, 2010-09-27 at 11:35 -0400, Eran Hammer-Lahav wrote:
> This is a stupid discussion. We have been talking past each other (the
> working group) for over a year. We are not likely to convince either
> side that bearer tokens are bad or good idea.
> 
>  
> 
> All these experts reviewed WRAP in the strict context of their own
> environment, with existing protocols and other weaknesses. Other and I
> are reviewing it in the wider context of what is good for the web, and
> am much less concerned about complexity. IOW, I don’t believe that in
> this case WRAP made the right choice between developer ease and
> security.
> 
>  
> 
> This is also exactly the problem with the current specification. New
> readers are more likely to assume that what is good for these big
> companies is also good for them, without making their own threat model
> analysis. How would they reach any other conclusion when the
> specification doesn’t offer a complete alternative?
> 
>  
> 
> We should focus on finding a compromise everyone can live with, since
> clearly debating the two sides has produced nothing. I think
> positioning bearer tokens as the primary mechanism, but including a
> signature alternative in the same specification is a reasonable
> compromise. Bearer token fans get the spotlight, while those looking
> for a signature (providing the same protections as 1.0a HMAC-SHA-1)
> get some algorithm included.
> 
>  
> 
> I'll echo John's comments and remind you that Micrsoft, Yahoo! and
> Google security experts with plenty of real world experience worked on
> WRAP which is OAuth bearer tokens.
> 
>  
> 
> 
> Microsoft, Google, Salesforce, Facebook and others have deployed
> bearer token OAuth in production after internal security reviews. I
> don't think that is a personal opinion, that is fact. 
> 
>  
> 
> 
> wrt. another comment you had about security considerations, Brian
> Eaton did write up a bunch of security considerations for WRAP.
> 
> 
>  
> 
> Actually in [1], Ben Laurie does not say that a simple reference to
> TLS is a recipe for disaster.  (Go read it.)  In fact his first point
> is that you need a well-define threat model before you can talk
> sensibly about any of this; I would really like us to do that in this
> case too.
> 
> 
>  
> 
> 
>         People tend to implement TLS incorrectly on the client side
>         which voids many of the important protections it is meant to
>         provide.
>         
>  
> 
> 
> checking for certificate revocations) seem to me to be very general
> and exactly the kinds of things one needs in order to implement _any_
> protection against the endpoint impersonation you are worried about.
>  Why would they be more likely to get it right for a new protocol than
> for an existing one?
> 
> 
>  
> 
> 
>         
>         As the editor, I am having a hard time consolidating your view
>         which treats readers as security experts, capable of making
>         educated decisions about the protocol, and the demands from
>         others that the specification should be completely accessible
>         to any developer (especially those with no security
>         If we want to keep the full range, we need to clearly express
>         it, including highlighting the significant shortcomings of
>         bearer tokens, the known TLS deployment issues, and the value
>         in whatever signature proposals we have ready to reference or
>         include.
>         
>         Standards are meant to improve interoperability, but also
>         security. This is why any IETF charter dealing with an
>         existing technology states that the working group may break
>         compatibility if it has interop or security reasons to do so.
>         We are doing fine on interop, but doing pretty badly on
>         security.
>         
>         EHL
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 27 Sep 2010 13:53:23 -0700

On 2010-09-27, at 11:25 AM, Torsten Lodderstedt wrote:

> I don't understand why signing tokens and signing message shall be solved with the same solution.

They don't have to use the same solution, but you have the same issues (discovery, key management) in both cases, so why not solve them the same way?

> 
> In my opinion, tokens are opaque to any client and are just passed through as an uninterpreted string from authorization server (AS) to the resource server (RS) via the client. So the OAuth spec does not necessarily have to standardize their format (incl. signatures) in order to facilitate protocol interoperability. AS and RS just have to use the same format. Since both have a thight relationship that should not be a problem. If one like it can use an existing formats like SAML assertions or SWT.

If the AS and RS are tightly bound, then the token can be opaque. If there is one to many or many to many relationships, then you need a standard token, and for scale, you want to sign the token.

> 
> That's completely different from message signing. Here all parties are involved. So any client accessing a pair of AS and RS has to know how to sign a message in order to prove legitimate token ownership and/or protect the message from modifications.

See point above.

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 27 Sep 2010 21:48:00 -0700

Are you going to write it? Still waiting for the best practices guide for 1.0 people suggested over three years ago.

EHL

> From: Justin Richer [mailto:[email-masked]]
> Sent: Monday, September 27, 2010 12:04 PM
> To: Eran Hammer-Lahav
> Cc: Dick Hardt; OAuth WG
> "developers guide" from the "protocol spec" for a while now. I believe that
> they support two different audiences.
> 
> selecting profiles of those specs, and laying out exactly what's happening at
> each step for people to follow.
> 
>  -- Justin
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 28 Sep 2010 07:44:33 +0200

> They don't have to use the same solution, but you have the same issues (discovery, key management) in both cases, so why not solve them the same way?

This depends on the objective. Message signing and prove of possession 
can be achieved using AS generated short-living token secrets. I don't 
see a need for discovery here. I agree for all other use cases.

> If the AS and RS are tightly bound, then the token can be opaque. If there is one to many or many to many relationships, then you need a standard token, and for scale, you want to sign the token.

Even for the such relationships between AS and RS, the token can be 
opaque wrt the client.

Please note: I didn't argue against having a standardized token format 
or signing self-contained tokens. But in contrast to message signing 
between client and RS, this is in my opinion not required for achieving 
a reasonable security level and interop in the first step. If the WG 
wants to achieve interop between independent AS and RS, this should 
explicitely stated somewhere and would have significant impact all over 
the spec. So far we don't even have a way to identify RSs in a portable 
way. WG consensous was to let this aspect be deployment specific.

regards,
Torsten.

---

From: Justin Richer <[email-masked]>
Date: Tue, 28 Sep 2010 09:31:30 -0400

Yes, I'm willing to write guides for the profiles that I use, once
things settle down and we know what the protocol actually is. :) I'd
argue that Facebook's developer docs are a start for "bearer tokens
using the UX extension and web server/user agent profiles" already.

I think that the most sensible place to put things like this would be
the oauth.net wiki.

 -- Justin