Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2

From: Dirk Balfanz <[email-masked]>
Date: Thu, 20 May 2010 16:39:23 -0700

Hi guys,

at today's interim meeting, we were discussing Brian Eaton's proposal for
OAuth signatures. He was proposing a mechanism that would (1) do away with
base string canonicalization, (2) allow for symmetric and public keys, and
(3) allow for extensibility.

He got homework from the group to prove the feasibility of his proposal by
showing a couple of implementations.

In this post, I would like to introduce another improvement of the OAuth 2
signing mechanism, one which is orthogonal to Brian's proposal (i.e., it
would work both with the signing mechanism in the current spec, as well as
with Brian's signature mechanism). The goal of my proposal is twofold:

- it simplifies the spec. It will become more readable and therefore easier
to implement
- it separates out the mechanisms for delegated authorization and for
integrity protection into two independent pieces, which can be put together
by Servers and/or Clients like LEGO blocks.

Summary:

- use the client secret instead of the token secret for signing PR access
requests.

Long version of the proposal:

- remove all references to access tokens that are not bearer tokens from the
spec.
- stop calling the access tokens "bearer tokens". Call them just "access
tokens".
- remove all references to token secrets from the spec
- remove all parts of the spec that are of the kind "if bearer_token then X,
else Y", and replace them with X.
- delete section 5.3
- add a section called "Request Authentication" that goes something like
this:

"Servers may require that requests be authenticated by the Client, so that
presentation of the access token alone is not sufficient to access a
Protected Resource.  This has several use cases, including, but not limited
to, the following:

- Non-repudiation: high-security deployments may require that requests be
authenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that access
tokens may leak.
- End-to-end-integrity: even if SSL _is_ used, network infrastructure may
strip SSL protection before the request reaches the protected resource. The
protected resource, however, may require end-to-end integrity.

If the Server requires that the Client authenticate PR access requests, then
the Client uses the following mechanism to sign their HTTP requests: [...]"

Then, we basically drop the old Section 5.3 here (except we use the client
secret instead of the access token secret). Eventually, instead of Section
5.3, we may have Brian's new signature scheme section here, which would add
the option of public-key crypto[1], etc.

What do you guys think?

Dirk.

[1] Technically speaking, the goal of non-repudiation can only be achieved
once we have public-key crypto.

---

From: David Recordon <[email-masked]>
Date: Thu, 20 May 2010 17:44:56 -0700

We're able to use the client secret for signing requests instead of a token
secret, but my understanding is that this exists because of deployers who do
not wish for their protected resources to have access to client secrets.

--David

On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz <[email-masked]> wrote:

> - remove all references to access tokens that are not bearer tokens from
> the spec.
> - remove all parts of the spec that are of the kind "if bearer_token then
> X, else Y", and replace them with X.
> - delete section 5.3
> If the Server requires that the Client authenticate PR access requests,
> then the Client uses the following mechanism to sign their HTTP requests:
> [...]"
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Allen Tom <[email-masked]>
Date: Thu, 20 May 2010 19:35:56 -0700

Hi Dirk-

We at Yahoo would be very much against using the client secret for signing
requests to Protected Resources, since this would require that the client
secret be distributed to the PR endpoints. For security reasons, one of the
design goals for WRAP was to keep the client secret a secret between only
the AS and the Client  deliberately separating the authentication of the
client (on the AS) from the serving of the protected resource.

>From your post, it¹s not quite clear what the disadvantage is with using the
Access Token secret for generating signatures.

(forgive me if this was already discussed today - I was very zonked out
after 3 days of IIW)

Thanks
Allen

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 21 May 2010 13:14:07 +1000

Dirk,

A good approach would be to define a generic mechanism (say "MAC") for signing a request with a secret key. Define it to take two identities: an identity associated with the key (authentication identity); and another (~identity to act as / authorization identity / token). This mechanism needs zero dependence on OAuth.
[See section 2 "Identity Concepts" in RFC4422 "Simple Authentication and Security Layer (SASL)"]

Then define how an OAuth2 flow can tell a client to use the MAC scheme, with the OAuth2 access_token as the "other identity" (and the client_secret as the signing key).

Examples:

OAuth2 flow results in the following access token response:
  { "scheme":"MAC", "access_token":"efwthfeytf2e3" }
The client then sends requests to protected resource with:
  Authorization: MAC access_token=efwthfeytf2e3; keyid=<client_id>; sig=<signature using client_secret> ...

A different service wants to issue tokens and secrets. Its OAuth2 access token response is:
  { "scheme":"MAC", "access_token":"efwthfeytf2e3", "keyid":"3265462223", "secret":"hjgGJF66GHF" }
The client then sends requests to protected resource with:
  Authorization: MAC access_token=efwthfeytf2e3; keyid=3265462223; sig=<signature using hjgGJF66GHF> ...

A third service wants to use bearer tokens. Its access token response is:
  { "scheme":"Token", "access_token":"efwthfeytf2e3" }
The client then sends requests to protected resource with:
  Authorization: Token access_token=efwthfeytf2e3

The idea is that the access token response acts a bit like a WWW-Authenticate response header (telling the client how to make authentic requests), and provides some of the credentials to use.
If a server indicates an auth scheme that needs a secret but doesn't provide it, then the client knows to use its own client_secret.

--
James Manger 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dirk Balfanz
Sent: Friday, 21 May 2010 9:39 AM
To: OAuth WG
Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2

...
In this post, I would like to introduce another improvement of the OAuth 2 signing mechanism, one which is orthogonal to Brian's proposal (i.e., it would work both with the signing mechanism in the current spec, as well as with Brian's signature mechanism). The goal of my proposal is twofold:

- it simplifies the spec. It will become more readable and therefore easier to implement
- it separates out the mechanisms for delegated authorization and for integrity protection into two independent pieces, which can be put together by Servers and/or Clients like LEGO blocks.

Summary:

- use the client secret instead of the token secret for signing PR access requests.
...

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 20 May 2010 23:34:08 -0700

> -----Original Message-----
> Sent: Thursday, May 20, 2010 4:39 PM
> To: OAuth WG
> OAuth signatures. He was proposing a mechanism that would (1) do away
> with base string canonicalization, (2) allow for symmetric and public keys, and

It doesn't get rid of the base string canonicalization; it just moves the pieces around with different benefits and tradeoffs. It might be a better rearrangement since it moves the complexity from the client to the server, but your characterization is misleading. I'll wait for Brian to post his proposal to the list before an in-depth discussion.

EHL

---

From: Dirk Balfanz <[email-masked]>
Date: Fri, 21 May 2010 08:39:43 -0700

On Thu, May 20, 2010 at 11:34 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> It doesn't get rid of the base string canonicalization; it just moves the
> pieces around with different benefits and tradeoffs. It might be a better
> rearrangement since it moves the complexity from the client to the server,
> but your characterization is misleading. I'll wait for Brian to post his
> proposal to the list before an in-depth discussion.
>

Sorry - I didn't mean to jump to conclusions about Brian's proposal. Do you
agree, though, that my refactoring proposal is orthogonal to whether we'll
agree to Brian's new signature scheme?

Dirk.

---

From: Dirk Balfanz <[email-masked]>
Date: Fri, 21 May 2010 08:38:04 -0700

On Thu, May 20, 2010 at 7:35 PM, Allen Tom <[email-masked]> wrote:

> the AS and the Client – deliberately separating the authentication of the

I understand - and I'm not taking that away: you still have access tokens,
which are the short-lived secrets that you expose to your PR endpoints.
Yahoo! would presumably rely on SSL for request integrity instead, or use
"Request Authentication" only with public-key signatures.

>
> From your post, it’s not quite clear what the disadvantage is with using
> the Access Token secret for generating signatures.
>

Well, there is the problem that the spec itself is a bit awkward right now
with the access tokens-vs.-bearer tokens language all over the place. There
are things in there that I think are unnecessary, like secret type, access
token secret, etc. (the access token itself is supposed to be that secret).

Then, there is the issue of "re-factoring" the spec. The access token serves
the function of delegated authorization. I give you an access token, now you
have certain privileges that I delegated to you. We decided to use this
"capability" model for OAuth instead of ACLs, and I think it proves
powerful. So what's signing for, then? It's for authenticating who is
currently using the access token, which has some use cases that I'm trying
to call out in my proposal. But that's a different function, so it should be
served by a separate mechanism (frankly, I'd be happy if that was in a
completely different spec, but I think that train has left the station).

Finally, why client secret (or client private key) instead of token secret?
Because I believe that actually better reflects what the signing is for -
authenticating who is currently using the token. Two of the three use cases
I outlined above can't be met with access token secrets: Access token
secrets are known to the Server infrastructure, and therefore you don't get
non-repudiation and end-to-end integrity, you only get protection from
leaked access tokens.

Does this make sense?

Dirk.

>
> (forgive me if this was already discussed today - I was *very* zonked out
> after 3 days of IIW)
>
> Thanks
> Allen
>
>
>
>
> ------------------------------

---

From: Dirk Balfanz <[email-masked]>
Date: Fri, 21 May 2010 13:29:30 -0700

That would be fine with me, but I think people really like to have
signatures as a part of core OAuth. I don't feel strongly about it either
way.

One nit-pick, though: the other spec (which, in my proposal, is simply a new
section in the OAuth spec), wouldn't be about "signed tokens". The way I see
it, there should be only one kind of token - you can't use it to sign
things, you simply include it in your requests. Whether those requests come
in the clear, over SSL, or are otherwise signed, is a different question.
The token shouldn't have anything to do with request signing: In the case of
SSL, for example, the requests are signed (using a shared secret negotiated
during the SSL handshake), but the token has nothing to do with that
signature. In the case where we don't use SSL, yet still want to sign the
requests, the same should be true: the signature on the request should have
nothing to do with the token - the token and the signature serve two
different purposes.

Fortunately, we have a secret we can use for the signature: the OAuth client
secret (and hopefully, in a future rev of the spec, the client private key)
- so it makes sense to make this request signing be at least a companion
spec to OAuth, if not a section of the spec itself.

Dirk.

On Fri, May 21, 2010 at 11:27 AM, Richer, Justin P. <[email-masked]>wrote:

> I have a slightly more radical proposal. What if we factor out the signed
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, given
> the same attention by the group and all that like Eran was talking about
> yesterday. What this would take is taking out all reference to signing and
> making core OAuth just about bare tokens, then have a separate spec that
> details what to call your shared secret parameters, how to get them, and how
> to sign with them. This makes the core spec a lot simpler (as detailed
> below) but makes the overall use case of using signed tokens more
> complicated to follow, as it'd be split in two.
>
>  -- justin
> ________________________________________
> From: [email-masked] [[email-masked]] On Behalf Of Dirk
> Balfanz [[email-masked]]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG

---

From: John Panzer <[email-masked]>
Date: Fri, 21 May 2010 21:15:45 -0700

Dirk: How would sub-delegation of an access token work in your
proposal?  In other words I hand my AT to a sub-contractor.  Who may
call on Apis that do not require a signature from them; or they may,
and therefore need their own relationship with the service. But it's
up to the service and could depend in the API and access needed.
Seems like separation of concerns makes this easier.

On Friday, May 21, 2010, Dirk Balfanz <[email-masked]> wrote:
> That would be fine with me, but I think people really like to have signatures as a part of core OAuth. I don't feel strongly about it either way.
>  One nit-pick, though: the other spec (which, in my proposal, is simply a new section in the OAuth spec), wouldn't be about "signed tokens". The way I see it, there should be only one kind of token - you can't use it to sign things, you simply include it in your requests. Whether those requests come in the clear, over SSL, or are otherwise signed, is a different question. The token shouldn't have anything to do with request signing: In the case of SSL, for example, the requests are signed (using a shared secret negotiated during the SSL handshake), but the token has nothing to do with that signature. In the case where we don't use SSL, yet still want to sign the requests, the same should be true: the signature on the request should have nothing to do with the token - the token and the signature serve two different purposes.
>
> Fortunately, we have a secret we can use for the signature: the OAuth client secret (and hopefully, in a future rev of the spec, the client private key) - so it makes sense to make this request signing be at least a companion spec to OAuth, if not a section of the spec itself.
>
> Dirk.
>
> On Fri, May 21, 2010 at 11:27 AM, Richer, Justin P. <[email-masked]> wrote:
>
> I have a slightly more radical proposal. What if we factor out the signed token use case into a parallel spec? The OAuth 2.0 Signed Token spec, given the same attention by the group and all that like Eran was talking about yesterday. What this would take is taking out all reference to signing and making core OAuth just about bare tokens, then have a separate spec that details what to call your shared secret parameters, how to get them, and how to sign with them. This makes the core spec a lot simpler (as detailed below) but makes the overall use case of using signed tokens more complicated to follow, as it'd be split in two.
>
>  -- justin
> From: [email-masked] [[email-masked]] On Behalf Of Dirk Balfanz [[email-masked]]
> at today's interim meeting, we were discussing Brian Eaton's proposal for OAuth signatures. He was proposing a mechanism that would (1) do away with base string canonicalization, (2) allow for symmetric and public keys, and (3) allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposal by showing a couple of implementations.
>
> - remove all references to access tokens that are not bearer tokens from the spec.
> - stop calling the access tokens "bearer tokens". Call them just "access tokens".
> - remove all parts of the spec that are of the kind "if bearer_token then X, else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes something like this:
>
> "Servers may require that requests be authenticated by the Client, so that presentation of the access token alone is not sufficient to access a Protected Resource.  This has several use cases, including, but not limited to, the following:
>
> - Non-repudiation: high-security deployments may require that requests be authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that access tokens may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure may strip SSL protection before the request reaches the protected resource. The protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests, then the Client uses the following mechanism to sign their HTTP requests: [...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the client secret instead of the access token secret). Eventually, instead of Section 5.3, we may have Brian's new signature scheme section here, which would add the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achieved once we have public-key crypto.
>
>
>
>

-- 
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: Justin Smith <[email-masked]>
Date: Sat, 22 May 2010 05:20:10 +0000

I like the idea of simplifying the core spec, but the devil is in the details.

In practice it seems onerous to ask the AS and the PR to know both the key used to sign the token as well as the key used to sign the request (regardless of if the request signing key is the same as the client_secret).

I'm also not sure the bearer token / access token language works even with the existing section 5.3. As Dirk points out, choosing to "sign" the request is independent of the AS issued token. Does anyone think it is necessary to keep the bearer / access token language as is?

FWIW, I'm in favor of moving the request signing into a companion spec.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dirk Balfanz
Sent: Friday, May 21, 2010 1:29 PM
To: Richer, Justin P.
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2

Dirk.
On Fri, May 21, 2010 at 11:27 AM, Richer, Justin P. <[email-masked]<mailto:[email-masked]>> wrote:
I have a slightly more radical proposal. What if we factor out the signed token use case into a parallel spec? The OAuth 2.0 Signed Token spec, given the same attention by the group and all that like Eran was talking about yesterday. What this would take is taking out all reference to signing and making core OAuth just about bare tokens, then have a separate spec that details what to call your shared secret parameters, how to get them, and how to sign with them. This makes the core spec a lot simpler (as detailed below) but makes the overall use case of using signed tokens more complicated to follow, as it'd be split in two.

 -- justin
________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Dirk Balfanz [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, May 20, 2010 7:39 PM
To: OAuth WG
Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2
Hi guys,

Summary:

What do you guys think?

Dirk.

---

From: Dirk Balfanz <[email-masked]>
Date: Fri, 21 May 2010 22:58:40 -0700

> Seems like separation of concerns makes this easier.

Yes, my proposal allows the PR to decide whether or not they allow such
sub-delegation. You could imagine servers that don't care - whoever shows up
with the bearer token has access. You could imagine servers that don't allow
sub-delegation at all - and they would use this signature scheme as a way to
enforce it. And you could imagine servers somewhere in the middle - they
accept tokens from a sub-delegatee as long as the original Client has told
the Server that they're sub-delegating to that particular sub-delegatee.
Only the first of those is possible with token-secret-signatures. All three
are possible with client-secret signatures.

Dirk.

> >  One nit-pick, though: the other spec (which, in my proposal, is simply a
> new section in the OAuth spec), wouldn't be about "signed tokens". The way I
> see it, there should be only one kind of token - you can't use it to sign
> > Fortunately, we have a secret we can use for the signature: the OAuth
> client secret (and hopefully, in a future rev of the spec, the client
> private key) - so it makes sense to make this request signing be at least a
> companion spec to OAuth, if not a section of the spec itself.
> >
> > Dirk.
> >
> > In this post, I would like to introduce another improvement of the OAuth
> 2 signing mechanism, one which is orthogonal to Brian's proposal (i.e., it
> > "Servers may require that requests be authenticated by the Client, so
> that presentation of the access token alone is not sufficient to access a
> > Then, we basically drop the old Section 5.3 here (except we use the
> client secret instead of the access token secret). Eventually, instead of
> Section 5.3, we may have Brian's new signature scheme section here, which
> would add the option of public-key crypto[1], etc.
> >
> > What do you guys think?
> >
> > Dirk.
> >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 22 May 2010 10:59:23 +0200

Assume "client secret" means the secret issued by the OAuth AS to its 
clients, I think this client secret should be used to authenticate 
clients to the AS only. All other authentication (e.g. against PR) can 
be based on that trust anchor. I don't mind using the secret to sign AS 
requests. But here at Deutsche Telekom, we don't want to sign PR 
requests with the client secret because this requires a strong coupling 
between AS and PR. Our aim is to operate PR's and AS as independently as 
possible.

I think the token secret is fine for signing PR requests and proving 
legitimate token ownership. It is issued after the client has succefully 
authenticated on the AS and thus transitively asserts its identity to 
the PR. Moreover, the secret can be passed from AS to PR as (encrypted) 
part of the access token. So the coupling between AS and PR is loose. 
That pattern is well-known from Kerberos and proven in the wild.

One could use another PR-specific client-secret to sign PR requests. But 
that's out of OAuth2-scope, from my point of view.

regards,
Torsten.

Am 21.05.2010 01:39, schrieb Dirk Balfanz:
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's proposal 
> for OAuth signatures. He was proposing a mechanism that would (1) do 
> away with base string canonicalization, (2) allow for symmetric and 
> public keys, and (3) allow for extensibility.
>
> He got homework from the group to prove the feasibility of his 
> proposal by showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the 
> OAuth 2 signing mechanism, one which is orthogonal to Brian's proposal 
> (i.e., it would work both with the signing mechanism in the current 
> spec, as well as with Brian's signature mechanism). The goal of my 
> proposal is twofold:
>
> integrity protection into two independent pieces, which can be put 
> together by Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - remove all parts of the spec that are of the kind "if bearer_token 
> then X, else Y", and replace them with X.
> - delete section 5.3
> that presentation of the access token alone is not sufficient to 
> access a Protected Resource.  This has several use cases, including, 
> but not limited to, the following:
>
> - Non-repudiation: high-security deployments may require that requests 
> be authenticated (signed) in a non-repudiateable way[1]
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure 
> may strip SSL protection before the request reaches the protected 
> resource. The protected resource, however, may require end-to-end 
> integrity.
>
> If the Server requires that the Client authenticate PR access 
> requests, then the Client uses the following mechanism to sign their 
> HTTP requests: [...]"
>
> client secret instead of the access token secret). Eventually, instead 
> of Section 5.3, we may have Brian's new signature scheme section here, 
> which would add the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 21 May 2010 14:27:24 -0400

-- justin

Hi guys,

Summary:

What do you guys think?

Dirk.

---

From: Dirk Balfanz <[email-masked]>
Date: Mon, 24 May 2010 09:06:56 -0700

On Sat, May 22, 2010 at 1:59 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> clients, I think this client secret should be used to authenticate clients
> to the AS only. All other authentication (e.g. against PR) can be based on
> that trust anchor. I don't mind using the secret to sign AS requests. But
> here at Deutsche Telekom, we don't want to sign PR requests with the client
> secret because this requires a strong coupling between AS and PR. Our aim is
> to operate PR's and AS as independently as possible.
>

That's fine - you can use public-key signatures (i.e., the client signs the
HTTP request with their private key) or bearer tokens over SSL to achieve
that goal. In both cases, the PRs don't need to know a secret shared between
the Client and the AS.

> legitimate token ownership.
>

Assuming that the token secret is somehow better protected than the token
itself, then yes, it is. But as I pointed out, it needlessly complicates the
spec, and fails to address certain use cases that people want.

> It is issued after the client has succefully authenticated on the AS and
> thus transitively asserts its identity to the PR. Moreover, the secret can
> be passed from AS to PR as (encrypted) part of the access token. So the
> coupling between AS and PR is loose. That pattern is well-known from
> Kerberos and proven in the wild.
>

Kerberos is a different protocol - I would caution against drawing parallels
and assuming that we obtain certain properties from Kerberos because we
(superficially) follow flows that sort-of look like Kerberos (for starters,
we use signatures, they use encryption, but there are other differences).
Having said that, the loose coupling between between AS and PR is certainly
something that Kerberos also has. Which I don't want to take away. Bearer
tokens give you that. Bearer tokens over SSL give you that. We don't need
signatures for that.

I'm arguing that signatures can give us properties that Kerberos _doesn't_
have, i.e, non-repudiation and end-to-end integrity: In Kerberos, the
Service Server can't tell the difference between the Client and the
Ticket-Granting Server. The Ticket-Granting Server can't tell the difference
between the Client and the Authentication Server. If we ever want to build
an LoA2 or LoA3 auth protocol on top of OAuth2, that's not good enough.

Dirk.

> [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Allen Tom <[email-masked]>
Date: Tue, 25 May 2010 18:56:06 -0700

+1

I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels
of security than what bearer tokens can provide.

That being said, I think that bearer token/refresh token model can satisify
the majority of use cases - in fact it would satisfy 100% of all public APIs
that we have at Yahoo.

Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused
solely on uses cases that require a signature?

Allen

On 5/21/10 11:27 AM, "Richer, Justin P." <[email-masked]> wrote:

> to sign with them. This makes the core spec a lot simpler (as detailed below)
> but makes the overall use case of using signed tokens more complicated to
> follow, as it'd be split in two.
> 
>  -- justin
> base string canonicalization, (2) allow for symmetric and public keys, and (3)
> allow for extensibility.
> 
> signing mechanism, one which is orthogonal to Brian's proposal (i.e., it would
> work both with the signing mechanism in the current spec, as well as with
> Brian's signature mechanism). The goal of my proposal is twofold:
> 
> integrity protection into two independent pieces, which can be put together by
> Servers and/or Clients like LEGO blocks.
> 
> Summary:
> 
> presentation of the access token alone is not sufficient to access a Protected
> Resource.  This has several use cases, including, but not limited to, the
> following:
>

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 26 May 2010 11:42:05 -0400

+1 also. A separate signatures/tokens spec would be useful.

If service providers in the future wish to use OAuth for
authenticating users within transactions with assurance higher than LOA1,
then I strongly suggest the issue of non-repudiation is addressed.
Logging/auditing/tracking is huge issue in some environments.

/thomas/

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Allen Tom
> Sent: Tuesday, May 25, 2010 9:56 PM
> To: Richer, Justin P.; Dirk Balfanz; OAuth WG
> below)
> would
> to
> > implement
> the
> Protected
> tokens
> > may leak.
> then

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 26 May 2010 10:44:06 -0700

Repeating what I said before:

- separate spec is fine by me
- part of the point I'm trying to make is that that spec shouldn't be about
signed _tokens_, but instead about signed _HTTP requests_ (so instead of
merely proving that you know a secret that came with the token, you  prove
who you are when you use the token).

I'd be interested what the Facebook guys think about this - I believe the
current signature scheme is in there mostly to address a use case they had.

Luke, Dave - would a separate signing spec be ok with you guys?

Dirk.

On Tue, May 25, 2010 at 6:56 PM, Allen Tom <[email-masked]> wrote:

> with
> 2
> > - it simplifies the spec. It will become more readable and therefore
> easier to
> > implement
> that
> client

---

From: David Recordon <[email-masked]>
Date: Wed, 26 May 2010 11:55:29 -0600

I'd prefer that we keep signatures simple enough that they can remain in the
core spec.

--David

On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz <[email-masked]> wrote:

>> for
>> be
>> may

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 26 May 2010 11:15:18 -0700

Ok - to those advocating a separate spec: What if the separate spec was
really simple (a couple of pages), and we just pasted it as "Section X" into
the core OAuth spec?

To Facebook: What if the core OAuth spec had a section called "Signed OAuth
Requests" that (in its extreme form) had the single sentence: "If PRs
require signing, then Clients use the XYZ mechanism to sign their OAuth
requests" (with a link to XYZ)?

Dirk.

On Wed, May 26, 2010 at 10:55 AM, David Recordon <[email-masked]>wrote:

> I'd prefer that we keep signatures simple enough that they can remain in
> the core spec.
>
> --David
>
>
>
>> - part of the point I'm trying to make is that that spec shouldn't be
>> about signed _tokens_, but instead about signed _HTTP requests_ (so instead
>> of merely proving that you know a secret that came with the token, you
>>  prove who you are when you use the token).
>>
>>> OAuth 2

---

From: David Recordon <[email-masked]>
Date: Wed, 26 May 2010 12:20:09 -0600

How about we figure out the technical details of signatures before figuring
out where they're placed? :) </bikeshed>

On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz <[email-masked]> wrote:

>> On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz <[email-masked]>wrote:
>>
>>>> > - Access to protected resources is not protected by SSL, so that
>>>> access tokens
>>>> > may leak.
>>>> requests, then

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 26 May 2010 14:45:23 -0400

I'm fine with it staying as the new-and-improved section 5.3, but it seems like it would be a natural piece to be factored out. As an extension, it could say things like "For any flow, the AS can return a secret with the token" instead of having it be peppered through all sections like it is today. Maybe we can do that in an internal section? I'm not the wizard of normative language that Eran is. :) 

So really, I'm more arguing for refactoring, whether the language stays inside of the OAuth spec or beside it ends up being beside the point.

 -- justin
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Dirk Balfanz [[email-masked]]
Sent: Wednesday, May 26, 2010 2:15 PM
To: David Recordon
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2

Ok - to those advocating a separate spec: What if the separate spec was really simple (a couple of pages), and we just pasted it as "Section X" into the core OAuth spec?

To Facebook: What if the core OAuth spec had a section called "Signed OAuth Requests" that (in its extreme form) had the single sentence: "If PRs require signing, then Clients use the XYZ mechanism to sign their OAuth requests" (with a link to XYZ)?

Dirk.

On Wed, May 26, 2010 at 10:55 AM, David Recordon <[email-masked]<mailto:[email-masked]>> wrote:
I'd prefer that we keep signatures simple enough that they can remain in the core spec.

--David

On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz <[email-masked]<mailto:[email-masked]>> wrote:
Repeating what I said before:

- separate spec is fine by me
- part of the point I'm trying to make is that that spec shouldn't be about signed _tokens_, but instead about signed _HTTP requests_ (so instead of merely proving that you know a secret that came with the token, you  prove who you are when you use the token).

I'd be interested what the Facebook guys think about this - I believe the current signature scheme is in there mostly to address a use case they had.

Dirk.

On Tue, May 25, 2010 at 6:56 PM, Allen Tom <[email-masked]<mailto:[email-masked]>> wrote:
+1

Allen

On 5/21/10 11:27 AM, "Richer, Justin P." <[email-masked]<mailto:[email-masked]>> wrote:

> From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Dirk
> Balfanz [[email-masked]<mailto:[email-masked]>]
> [email-masked]<mailto:[email-masked]>

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

---

From: Luke Shepard <[email-masked]>
Date: Wed, 26 May 2010 14:17:56 -0700

So, when I argued for signatures, the specific use cases we are concerned with:

- Mobile handsets and networks that don't support SSL very well
- High-volume applications where SSL is a significant cost to both sides - for Facebook, the top few apps make up a significant amount of API traffic, so we could do signatures for them and not for everyone else

I expect that these are issues that others will encounter as they expand into these areas- especially on the mobile side. These are not Facebook-specific issues.

That said, I agree with David that we should just figure out what the signatures are - I don't really care where they live. If they need to live in a separate spec then whatever, as long as the specs interoperate very cleanly. But I would like to hear from other mobile developers if they have tried OAuth 2.0 with success (Brian, I think you mentioned you may have some data about that?)

On May 26, 2010, at 11:20 AM, David Recordon wrote:

How about we figure out the technical details of signatures before figuring out where they're placed? :) </bikeshed>

On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz <[email-masked]<mailto:[email-masked]>> wrote:
Ok - to those advocating a separate spec: What if the separate spec was really simple (a couple of pages), and we just pasted it as "Section X" into the core OAuth spec?

Dirk.

--David

Dirk.

Allen

<ATT00001..txt>

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 26 May 2010 17:34:37 -0400

But I thought that on the mobile side, TLS must be supported, and there 
are tons of 3GPP and ITU-T standards that require that.

I would like to understand better was is in the way of achieving that. 
(Luke, I am not challenging your argument, by the way; I just want to 
understand what prevents the deployment of what I thought were pretty 
stable technologies).

Another question:  Can we rely on the mobile phone authentication to 
establish the keys between the mobile and any relying party? In this 
case the keys would be distributed by a mobile provider.

Igor

Luke Shepard wrote:
> - High-volume applications where SSL is a significant cost to both 
> sides - for Facebook, the top few apps make up a significant amount of 
> API traffic, so we could do signatures for them and not for everyone else
>
> I expect that these are issues that others will encounter as they 
> expand into these areas- especially on the mobile side. These are not 
> Facebook-specific issues.
>
> That said, I agree with David that we should just figure out what the 
> signatures are - I don't really care where they live. If they need to 
> live in a separate spec then whatever, as long as the specs 
> interoperate very cleanly. But I would like to hear from other mobile 
> developers if they have tried OAuth 2.0 with success (Brian, I think 
> you mentioned you may have some data about that?)
>
>> How about we figure out the technical details of signatures before 
>> figuring out where they're placed? :) </bikeshed>
>>
>>
>>     Ok - to those advocating a separate spec: What if the separate
>>     spec was really simple (a couple of pages), and we just pasted it
>>     as "Section X" into the core OAuth spec?
>>
>>     To Facebook: What if the core OAuth spec had a section called
>>     "Signed OAuth Requests" that (in its extreme form) had the single
>>     sentence: "If PRs require signing, then Clients use the XYZ
>>     mechanism to sign their OAuth requests" (with a link to XYZ)?
>>
>>     Dirk.
>>
>>
>>     On Wed, May 26, 2010 at 10:55 AM, David Recordon
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>             - part of the point I'm trying to make is that that spec
>>             shouldn't be about signed _tokens_, but instead about
>>             signed _HTTP requests_ (so instead of merely proving that
>>             you know a secret that came with the token, you  prove
>>             I'd be interested what the Facebook guys think about this
>>             - I believe the current signature scheme is in there
>>             mostly to address a use case they had.
>>
>>             On Tue, May 25, 2010 at 6:56 PM, Allen Tom
>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>                 +1
>>
>>                 On 5/21/10 11:27 AM, "Richer, Justin P."
>>                 <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>                 > From: [email-masked]
>>                 <mailto:[email-masked]>
>>                 [[email-masked]
>>                 <mailto:[email-masked]>] On Behalf Of Dirk
>>                 > - it simplifies the spec. It will become more
>>                 readable and therefore easier to
>>                 > implement
>>                 > - Access to protected resources is not protected by
>>                 SSL, so that access tokens
>>                 > may leak.
>>                 > [email-masked] <mailto:[email-masked]>
>>             [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Brian Eaton <[email-masked]>
Date: Wed, 26 May 2010 16:01:44 -0700

> - Mobile handsets and networks that don't support SSL very well

We were initially worried about this when we moved GMail to
https-only.  Mobile app developers were concerned about latency and
battery life.  Neither proved to be an issue in practice.

> - High-volume applications where SSL is a significant cost to both sides -
> for Facebook, the top few apps make up a significant amount of API traffic,
> so we could do signatures for them and not for everyone else

SSL is fairly inexpensive for server-to-server calls.  The SSL session
is expensive to set-up (it requires an extra TCP round trip and a few
ms of CPU), but it's only negotiated once.  The session is then reused
for long periods of time (hours, or days).  HTTP persistent
connections are another win.

This does not cause any complexity at all on the client-side: SSL and
HTTP libraries do the right thing automatically.

On the server-side, you need to make sure that your SSL session caches
are getting a good cache hit rate.  This can be impacted both by
capacity and network configuration.  Configuration of load balancers
matters.

SSL hardware accelerators are another possible win on the server-side.
 They can reduce the CPU load.  But the session cache is the most
critical component for reducing latency.

Terminating SSL at load balancers is another option.  That integrates
the SSL session cache and the load balancer, which can make deployment
simpler.

(We now return you to your regularly scheduled program on JSON vs
form-encoding...)

Cheers,
Brian

---

From: Luke Shepard <[email-masked]>
Date: Wed, 26 May 2010 22:39:54 -0700

> battery life.  Neither proved to be an issue in practice.

I agree with you that battery life is likely not a concern, but when I talk with our mobile team, we have definitely had issues with SSL connections - and when we switch to HTTP things clear up. I am working to dig into the numbers and find out exactly which carriers cause issues but it at least has been an issue. When you say that it's not a concern, can you explain which types of applications you're talking about? Does GMail just fail some of the time or are there other workarounds you've implemented for the issues?

> connections are another win.

I agree that this is ideal. Let me get some more stats on this.

> the SSL session cache and the load balancer, which can make deployment

This is how Facebook does it - terminate at the load balancer. I'm worried more about latency than cost for other developers.

Don't get me wrong, I love SSL, I love the simplicity of it, and I hope we can make it work everywhere. I just want to make sure we address the real issues and don't treat it as a panacea.

---

From: Brian Eaton <[email-masked]>
Date: Thu, 27 May 2010 07:14:30 -0700

On Wed, May 26, 2010 at 10:39 PM, Luke Shepard <[email-masked]> wrote:
> I agree with you that battery life is likely not a concern, but when I talk with our
> mobile team, we have definitely had issues with SSL connections - and when
> we switch to HTTP things clear up. I am working to dig into the numbers and
> find out exactly which carriers cause issues but it at least has been an issue.
> When you say that it's not a concern, can you explain which types of
> applications you're talking about? Does GMail just fail some of the time or
> are there other workarounds you've implemented for the issues?

Interesting.  We moved both our mobile installed apps and our mobile
gmail web interface to encrypted connections without running into
this.

Keep me posted on what you find.

---

From: Dirk Balfanz <[email-masked]>
Date: Thu, 27 May 2010 08:41:25 -0700

Sorry, I didn't mean to turn this into a debate over whether we should have
signatures. I think you guys stated your case clearly, and there are other
use cases as well.

The questions I was trying to figure out was whether

- you'd be ok using the client secret to sign instead of the token secret (I
think I heard David say that that was ok),
- you'd be ok with a signature scheme that's sufficiently factored out of
the rest of the spec that it might warrant it's own companion spec (I agree
that this is getting close to bikeshed territory, so let's worry about this
once we know what the signatures look like).

Dirk.

On Wed, May 26, 2010 at 2:17 PM, Luke Shepard <[email-masked]> wrote:

> I expect that these are issues that others will encounter as they expand
> into these areas- especially on the mobile side. These are not
> signatures are - I don't really care where they live. If they need to live
> in a separate spec then whatever, as long as the specs interoperate very
> cleanly. But I would like to hear from other mobile developers if they have
> tried OAuth 2.0 with success (Brian, I think you mentioned you may have some
> data about that?)
>
>> To Facebook: What if the core OAuth spec had a section called "Signed
>> OAuth Requests" that (in its extreme form) had the single sentence: "If PRs
>>>> I'd be interested what the Facebook guys think about this - I believe
>>>> the current signature scheme is in there mostly to address a use case they
>>>> had.
>>>>

---

From: David Recordon <[email-masked]>
Date: Thu, 27 May 2010 09:56:21 -0600

I thought Allen clearly said that signing with the client secret won't work
for Yahoo!?

Hi Dirk-

Allen

On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz <[email-masked]> wrote:

> - you'd be ok using the client secret to sign instead of the token secret
> (I think I heard David say that that was ok),
> On Wed, May 26, 2010 at 2:17 PM, Luke Shepard <[email-masked]>wrote:
>
>> On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz <[email-masked]>wrote:
>>

---

From: Dirk Balfanz <[email-masked]>
Date: Thu, 27 May 2010 09:04:53 -0700

> I thought Allen clearly said that signing with the client secret won't work

Right - but he also said that they (i.e. Yahoo!) wouldn't need signatures at
all. So I think we're good from the Yahoo! side of things.

Allen - did I get this right?

Dirk.

>> Sorry, I didn't mean to turn this into a debate over whether we should
>> have signatures. I think you guys stated your case clearly, and there are
>> other use cases as well.
>>
>>> - High-volume applications where SSL is a significant cost to both sides
>>> - for Facebook, the top few apps make up a significant amount of API
>>> traffic, so we could do signatures for them and not for everyone else
>>>
>>>>>> On Tue, May 25, 2010 at 6:56 PM, Allen Tom <[email-masked]>wrote:
>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> > - it simplifies the spec. It will become more readable and
>>>>>>> therefore easier to
>>>>>>> > implement

---

From: Allen Tom <[email-masked]>
Date: Thu, 27 May 2010 09:58:37 -0700

The short summary is that Yahoo thinks that signatures should not be
required for most use cases. In the exceptional cases where signatures are
required, then it should be up to the service provider (and not the client)
to determine when they¹re required, and  which signature algorithm is to be
used.  Yahoo does not want to be forced to support signatures generated
using the client secret  we don¹t even want this to be an option for the
overwhelming majority of our APIs. Due to the way services are deployed at
Yahoo, our security team feels that in general, having PR endpoints validate
signatures computed using the client secret makes our overall system LESS
secure  since we¹d be forced to distribute client secrets to the PR
endpoints. Distributing the client secret to the PR endpoints is very
undesirable, since doing so requires that the PR endpoints have the same
level of security as the AS.

Having a clean separation between the AS and the PR was one of the goals of
Oauth-WRAP  and having the PR authenticate the client using the client
secret violates this goal.

That being said, Yahoo does have private/internal APIs which require a very
high level of security in which bearer tokens are not sufficient, and
signatures using the AT secret aren¹t sufficient either  in these cases,
signing the request with the client secret is probably the right way to go.
Again  this should be up to the SP to determine that a signature is
required, and how that signature is generated.

So what I¹m trying to say is  yes there are cases where it¹s desirable to
have stronger signatures than just signing with the AT secret  however I
think that the cases in which signatures are required, and which signature
algorithm is to be used should be entirely up to the SP.

Does that clarify things?
Allen

On 5/27/10 9:04 AM, "Dirk Balfanz" <[email-masked]> wrote:

>>>> tried OAuth 2.0 with success (Brian, I think you mentioned you may have
>>>> some data about that?)
>>>> 
>>>>>> really simple (a couple of pages), and we just pasted it as "Section X"
>>>>>> into the core OAuth spec?
>>>>>> 
>>>>>> OAuth Requests" that (in its extreme form) had the single sentence: "If
>>>>>> PRs require signing, then Clients use the XYZ mechanism to sign their
>>>>>> OAuth requests" (with a link to XYZ)?
>>>>>> 
>>>>>> Dirk.
>>>>>> 
>>>>>> 

Dirk.

Allen

---

From: George Fletcher <[email-masked]>
Date: Thu, 27 May 2010 14:11:40 -0400

Hmm... to me this says...

    Yahoo won't deploy PRs that require client_secret signatures, but
    may have some internal apps where this is ok.

    So, to me that sounds like Yahoo is ok with client_secret based
    signatures as one way to sign the requests, but they don't want it
    to be the only way.

I would like to bring back what Dirk has said earlier in this thread...

1. Signing isn't about the token but rather about the message
2. Signing provides message integrity
3. Signing provides (or should allow for) proof of sender

I'd like to add...
4. Signing (combined with appropriate information in the AT) enables 
"right to present" the token

I think that for certain use cases, its critical that the PR be able to 
ensure that the client is "authorized" to present the AT. This isn't 
possible for bearer tokens. I also don't believe this hurts 
sub-delegation because the AS can create an AT that can be sub-delegated 
and when the sub-delegate presents the AT, the PR can verify that the 
sub-delegate is allowed to present that AT.

Thanks,
George

On 5/27/10 12:58 PM, Allen Tom wrote:
> required for most use cases. In the exceptional cases where signatures 
> are required, then it should be up to the service provider (and not 
> the client) to determine when they're required, and  which signature 
> algorithm is to be used.  Yahoo does not want to be forced to support 
> signatures generated using the client secret -- we don't even want 
> this to be an option for the overwhelming majority of our APIs. Due to 
> the way services are deployed at Yahoo, our security team feels that 
> in general, having PR endpoints validate signatures computed using the 
> client secret makes our overall system LESS secure -- since we'd be 
> forced to distribute client secrets to the PR endpoints. Distributing 
> the client secret to the PR endpoints is very undesirable, since doing 
> so requires that the PR endpoints have the same level of security as 
> the AS.
>
> Having a clean separation between the AS and the PR was one of the 
> goals of Oauth-WRAP -- and having the PR authenticate the client using 
> the client secret violates this goal.
>
> That being said, Yahoo does have private/internal APIs which require a 
> very high level of security in which bearer tokens are not sufficient, 
> and signatures using the AT secret aren't sufficient either -- in 
> these cases, signing the request with the client secret is probably 
> the right way to go. Again -- this should be up to the SP to determine 
> that a signature is required, and how that signature is generated.
>
> So what I'm trying to say is -- yes there are cases where it's 
> desirable to have stronger signatures than just signing with the AT 
> secret -- however I think that the cases in which signatures are 
> required, and which signature algorithm is to be used should be 
> entirely up to the SP.
>
>         I thought Allen clearly said that signing with the client
>         secret won't work for Yahoo!?
>
>
>     Right - but he also said that they (i.e. Yahoo!) wouldn't need
>     signatures at all. So I think we're good from the Yahoo! side of
>     things.
>
>             We at Yahoo would be very much against using the client
>             secret for signing requests to Protected Resources, since
>             this would require that the client secret be distributed
>             to the PR endpoints. For security reasons, one of the
>             design goals for WRAP was to keep the client secret a
>             secret between only the AS and the Client -- deliberately
>             separating the authentication of the client (on the AS)
>             from the serving of the protected resource.
>
>             >From your post, it's not quite clear what the disadvantage
>             is with using the Access Token secret for generating
>             signatures.
>
>             (forgive me if this was already discussed today - I was
>             very zonked out after 3 days of IIW)
>
>             Thanks
>             Allen
>
>
>
>             Sorry, I didn't mean to turn this into a debate over
>             whether we should have signatures. I think you guys stated
>             your case clearly, and there are other use cases as well.
>
>             - you'd be ok using the client secret to sign instead of
>             the token secret (I think I heard David say that that was
>             ok),
>             - you'd be ok with a signature scheme that's sufficiently
>             factored out of the rest of the spec that it might warrant
>             it's own companion spec (I agree that this is getting
>             close to bikeshed territory, so let's worry about this
>                 - High-volume applications where SSL is a significant
>                 cost to both sides - for Facebook, the top few apps
>                 make up a significant amount of API traffic, so we
>                 could do signatures for them and not for everyone else
>
>                 I expect that these are issues that others will
>                 encounter as they expand into these areas- especially
>                 on the mobile side. These are not Facebook-specific
>                 issues.
>
>                 That said, I agree with David that we should just
>                 figure out what the signatures are - I don't really
>                 care where they live. If they need to live in a
>                 separate spec then whatever, as long as the specs
>                 interoperate very cleanly. But I would like to hear
>                 from other mobile developers if they have tried OAuth
>                 2.0 with success (Brian, I think you mentioned you may
>                 have some data about that?)
>
>                     How about we figure out the technical details of
>                     signatures before figuring out where they're
>                     placed? :) </bikeshed>
>
>
>                         Ok - to those advocating a separate spec: What
>                         if the separate spec was really simple (a
>                         couple of pages), and we just pasted it as
>                         "Section X" into the core OAuth spec?
>
>                         To Facebook: What if the core OAuth spec had a
>                         section called "Signed OAuth Requests" that
>                         (in its extreme form) had the single sentence:
>                         "If PRs require signing, then Clients use the
>                         XYZ mechanism to sign their OAuth requests"
>                         (with a link to XYZ)?
>
>                         Dirk.
>
>
>                         On Wed, May 26, 2010 at 10:55 AM, David
>                         Recordon <[email-masked]> wrote:
>
>                             I'd prefer that we keep signatures simple
>                             enough that they can remain in the core spec.
>
>                             --David
>
>
>
> about signed _tokens_, but instead about signed _HTTP requests_ (so 
> instead of merely proving that you know a secret that came with the 
> token, you  prove who you are when you use the token).
>
> the current signature scheme is in there mostly to address a use case 
> they had.
>

---

From: Dirk Balfanz <[email-masked]>
Date: Thu, 27 May 2010 11:32:33 -0700

On Thu, May 27, 2010 at 11:11 AM, George Fletcher <[email-masked]> wrote:

>  Yahoo won't deploy PRs that require client_secret signatures, but may
> have some internal apps where this is ok.
>
> So, to me that sounds like Yahoo is ok with client_secret based signatures
> as one way to sign the requests, but they don't want it to be the only way.
>
> Well the other proposal that's coming down the pipe is to re-introduce some
form of public key signatures (where the client secret is not a shared HMAC
key, but a private RSA key). Those would have all the properties you mention
below, plus the benefit that the PRs don't need to know the AS's secrets.

Dirk.

> 4. Signing (combined with appropriate information in the AT) enables "right
> to present" the token
>
> possible for bearer tokens. I also don't believe this hurts sub-delegation
> because the AS can create an AT that can be sub-delegated and when the
> sub-delegate presents the AT, the PR can verify that the sub-delegate is
> allowed to present that AT.
>
> Thanks,
> George
>
> to determine when they’re required, and  which signature algorithm is to be
> using the client secret – we don’t even want this to be an option for the
> secure – since we’d be forced to distribute client secrets to the PR
> Oauth-WRAP – and having the PR authenticate the client using the client
> signatures using the AT secret aren’t sufficient either – in these cases,
> Again – this should be up to the SP to determine that a signature is
> So what I’m trying to say is – yes there are cases where it’s desirable to
> have stronger signatures than just signing with the AT secret – however I
> Right - but he also said that they (i.e. Yahoo!) wouldn't need signatures
> at all. So I think we're good from the Yahoo! side of things.
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Raffi Krikorian <[email-masked]>
Date: Thu, 27 May 2010 11:41:53 -0700

sorry to jump in late here - but i would also be interested in making
signatures simple(r) to keep them in the core spec.  i would be very
interested in helping out on that front if need be.

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Dick Hardt <[email-masked]>
Date: Thu, 27 May 2010 13:13:29 -0600

Raffi: would you care to elaborate on Twittter's use case?

On 2010-05-27, at 12:41 PM, Raffi Krikorian wrote:

> sorry to jump in late here - but i would also be interested in making signatures simple(r) to keep them in the core spec.  i would be very interested in helping out on that front if need be.
> 
> On Wed, May 26, 2010 at 10:55 AM, David Recordon <[email-masked]> wrote:

---

From: Allen Tom <[email-masked]>
Date: Thu, 27 May 2010 13:08:48 -0700

Hi George,

The really short summary is that Yahoo is fine with client based signatures
being in the spec, although we do not want Service Providers to be obligated
to support them. The decision as to whether or not signatures should be
used, and which signature algorithm to use should be up to the Service
Provider.

We are very strongly against signatures generated using the client secret
for the overwhelming majority of our APIs  which is why we want the
signature algorithm to be chosen by the SP. A signature using the Access
Token secret (without the client secret) is OK, although it¹s unnecessary
for our applications.  A plain bearer token by itself (provided that it¹s
only valid for about an hour) is sufficient for all of Yahoo¹s services 
even without HTTPS.  We¹d rather increase security by deploying HTTPS rather
than requiring developers to sign their requests.

Thanks
Allen

On 5/27/10 11:11 AM, "George Fletcher" <[email-masked]> wrote:

>> Yahoo won't deploy PRs that require client_secret signatures, but may have
>> some internal apps where this is ok.
>>  
> 4. Signing (combined with appropriate information in the AT) enables "right to
> present" the token
> 
> I think that for certain use cases, its critical that the PR be able to ensure
> that the client is "authorized" to present the AT. This isn't possible for
> bearer tokens. I also don't believe this hurts sub-delegation because the AS
> can create an AT that can be sub-delegated and when the sub-delegate presents
> the AT, the PR can verify that the sub-delegate is allowed to present that AT.
> 
> Thanks,
> George
> 
>>  Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 The
>> short summary is that Yahoo thinks that signatures should not be required for
>> most use cases. In the exceptional cases where signatures are required, then
>> it should be up to the service provider (and not the client) to determine
>> when they¹re required, and  which signature algorithm is to be used.  Yahoo
>> does not want to be forced to support signatures generated using the client
>> secret  we don¹t even want this to be an option for the overwhelming
>> majority of our APIs. Due to the way services are deployed at Yahoo, our
>> security team feels that in general, having PR endpoints validate signatures
>> computed using the client secret makes our overall system LESS secure  since
>> we¹d be forced to distribute client secrets to the PR endpoints. Distributing
>> the client secret to the PR endpoints is very undesirable, since doing so
>> requires that the PR endpoints have the same level of security as the AS.
>>  
>>>>> secret be distributed to the PR endpoints. For security reasons, one of
>>>>> the design goals for WRAP was to keep the client secret a secret between
>>>>> only the AS and the Client  deliberately separating the authentication of
>>>>> the client (on the AS) from the serving of the protected resource.
>>>>>  
>>>>>> >From your post, it¹s not quite clear what the disadvantage is with using
>>>>> the rest of the spec that it might warrant it's own companion spec (I
>>>>> agree that this is getting close to bikeshed territory, so let's worry
>>>>> about this once we know what the signatures look like).
>>>>>  
>>>>>  Dirk.
>>>>>  
>>>>>  
>>>>>> live in a separate spec then whatever, as long as the specs interoperate
>>>>>> very cleanly. But I would like to hear from other mobile developers if
>>>>>> they have tried OAuth 2.0 with success (Brian, I think you mentioned you
>>>>>> may have some data about that?)
>>>>>>  

 Dirk.

On Wed, May 26, 2010 at 10:55 AM, David Recordon <[email-masked]>
wrote:

 --David

---

From: George Fletcher <[email-masked]>
Date: Thu, 27 May 2010 16:30:32 -0400

Thanks, makes sense. +1 to SP's deciding on what signature mech is 
required :)

On 5/27/10 4:08 PM, Allen Tom wrote:
> Hi George,
>
> The really short summary is that Yahoo is fine with client based 
> signatures being in the spec, although we do not want Service 
> Providers to be obligated to support them. The decision as to whether 
> or not signatures should be used, and which signature algorithm to use 
> should be up to the Service Provider.
>
> We are very strongly against signatures generated using the client 
> secret for the overwhelming majority of our APIs -- which is why we 
> want the signature algorithm to be chosen by the SP. A signature using 
> the Access Token secret (without the client secret) is OK, although 
> it's unnecessary for our applications.  A plain bearer token by itself 
> (provided that it's only valid for about an hour) is sufficient for 
> all of Yahoo's services -- even without HTTPS.  We'd rather increase 
> security by deploying HTTPS rather than requiring developers to sign 
> their requests.
>
> Thanks
> Allen
>
>
>         Yahoo won't deploy PRs that require client_secret signatures,
>         but may have some internal apps where this is ok.
>
>         So, to me that sounds like Yahoo is ok with client_secret
>         based signatures as one way to sign the requests, but they
>         don't want it to be the only way.
>
>
>     4. Signing (combined with appropriate information in the AT)
>     enables "right to present" the token
>
>     I think that for certain use cases, its critical that the PR be
>     able to ensure that the client is "authorized" to present the AT.
>     This isn't possible for bearer tokens. I also don't believe this
>     hurts sub-delegation because the AS can create an AT that can be
>     sub-delegated and when the sub-delegate presents the AT, the PR
>     can verify that the sub-delegate is allowed to present that AT.
>
>     Thanks,
>     George
>
>         Re: [OAUTH-WG] proposal for factoring out request signing in
>         OAuth 2 The short summary is that Yahoo thinks that signatures
>         should not be required for most use cases. In the exceptional
>         cases where signatures are required, then it should be up to
>         the service provider (and not the client) to determine when
>         they're required, and  which signature algorithm is to be
>         used.  Yahoo does not want to be forced to support signatures
>         generated using the client secret -- we don't even want this
>         to be an option for the overwhelming majority of our APIs. Due
>         to the way services are deployed at Yahoo, our security team
>         feels that in general, having PR endpoints validate signatures
>         computed using the client secret makes our overall system LESS
>         secure -- since we'd be forced to distribute client secrets to
>         the PR endpoints. Distributing the client secret to the PR
>         endpoints is very undesirable, since doing so requires that
>         the PR endpoints have the same level of security as the AS.
>
>         Having a clean separation between the AS and the PR was one of
>         the goals of Oauth-WRAP -- and having the PR authenticate the
>         client using the client secret violates this goal.
>
>         That being said, Yahoo does have private/internal APIs which
>         require a very high level of security in which bearer tokens
>         are not sufficient, and signatures using the AT secret aren't
>         sufficient either -- in these cases, signing the request with
>         the client secret is probably the right way to go. Again --
>         this should be up to the SP to determine that a signature is
>         desirable to have stronger signatures than just signing with
>         the AT secret -- however I think that the cases in which
>         signatures are required, and which signature algorithm is to
>         be used should be entirely up to the SP.
>
>                 I thought Allen clearly said that signing with the
>                 client secret won't work for Yahoo!?
>
>
>             Right - but he also said that they (i.e. Yahoo!) wouldn't
>             need signatures at all. So I think we're good from the
>             Yahoo! side of things.
>
>                     We at Yahoo would be very much against using the
>                     client secret for signing requests to Protected
>                     Resources, since this would require that the
>                     client secret be distributed to the PR endpoints.
>                     For security reasons, one of the design goals for
>                     WRAP was to keep the client secret a secret
>                     between only the AS and the Client -- deliberately
>                     separating the authentication of the client (on
>                     the AS) from the serving of the protected resource.
>
>                     >From your post, it's not quite clear what the
>                     disadvantage is with using the Access Token secret
>                     for generating signatures.
>
>                     (forgive me if this was already discussed today -
>                     I was very zonked out after 3 days of IIW)
>
>                     Thanks
>                     Allen
>
>
>
>                     Sorry, I didn't mean to turn this into a debate
>                     over whether we should have signatures. I think
>                     you guys stated your case clearly, and there are
>                     other use cases as well.
>
>                     - you'd be ok using the client secret to sign
>                     instead of the token secret (I think I heard David
>                     say that that was ok),
>                     - you'd be ok with a signature scheme that's
>                     sufficiently factored out of the rest of the spec
>                     that it might warrant it's own companion spec (I
>                     agree that this is getting close to bikeshed
>                     territory, so let's worry about this once we know
>                     what the signatures look like).
>
>                     Dirk.
>
>
>                         - High-volume applications where SSL is a
>                         significant cost to both sides - for Facebook,
>                         the top few apps make up a significant amount
>                         of API traffic, so we could do signatures for
>                         them and not for everyone else
>
>                         I expect that these are issues that others
>                         will encounter as they expand into these
>                         areas- especially on the mobile side. These
>                         are not Facebook-specific issues.
>
>                         That said, I agree with David that we should
>                         just figure out what the signatures are - I
>                         don't really care where they live. If they
>                         need to live in a separate spec then whatever,
>                         as long as the specs interoperate very
>                         cleanly. But I would like to hear from other
>                         mobile developers if they have tried OAuth 2.0
>                         with success (Brian, I think you mentioned you
>                             How about we figure out the technical
>                             details of signatures before figuring out
>                             where they're placed? :) </bikeshed>
>
>
> Ok - to those advocating a separate spec: What if the separate spec 
> was really simple (a couple of pages), and we just pasted it as 
> OAuth Requests" that (in its extreme form) had the single sentence: 
> "If PRs require signing, then Clients use the XYZ mechanism to sign 
> their OAuth requests" (with a link to XYZ)?
>
> Dirk.
>
>
>         shouldn't be about signed _tokens_, but instead about signed
>         _HTTP requests_ (so instead of merely proving that you know a
>         secret that came with the token, you  prove who you are when
>         you use the token).
>
>         I'd be interested what the Facebook guys think about this - I
>         believe the current signature scheme is in there mostly to
>         address a use case they had.
>
>         <[email-masked]> wrote:
>         +1
>
>         > - Access to protected resources is not protected by SSL, so
>         that access tokens
>         > may leak.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 29 May 2010 00:40:11 -0700

Sure, and add to that using bearer tokens too (i.e. providers can choose to only support signed requests if that suits them).

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Thursday, May 27, 2010 1:31 PM
To: Allen Tom
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2

Thanks, makes sense. +1 to SP's deciding on what signature mech is required :)

The really short summary is that Yahoo is fine with client based signatures being in the spec, although we do not want Service Providers to be obligated to support them. The decision as to whether or not signatures should be used, and which signature algorithm to use should be up to the Service Provider.

We are very strongly against signatures generated using the client secret for the overwhelming majority of our APIs - which is why we want the signature algorithm to be chosen by the SP. A signature using the Access Token secret (without the client secret) is OK, although it's unnecessary for our applications.  A plain bearer token by itself (provided that it's only valid for about an hour) is sufficient for all of Yahoo's services - even without HTTPS.  We'd rather increase security by deploying HTTPS rather than requiring developers to sign their requests.

Thanks
Allen

On 5/27/10 11:11 AM, "George Fletcher" <[email-masked]> wrote:
Hmm... to me this says...
Yahoo won't deploy PRs that require client_secret signatures, but may have some internal apps where this is ok.

 So, to me that sounds like Yahoo is ok with client_secret based signatures as one way to sign the requests, but they don't want it to be the only way.

I'd like to add...
4. Signing (combined with appropriate information in the AT) enables "right to present" the token

I think that for certain use cases, its critical that the PR be able to ensure that the client is "authorized" to present the AT. This isn't possible for bearer tokens. I also don't believe this hurts sub-delegation because the AS can create an AT that can be sub-delegated and when the sub-delegate presents the AT, the PR can verify that the sub-delegate is allowed to present that AT.

Thanks,
George

On 5/27/10 12:58 PM, Allen Tom wrote:
Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 The short summary is that Yahoo thinks that signatures should not be required for most use cases. In the exceptional cases where signatures are required, then it should be up to the service provider (and not the client) to determine when they're required, and  which signature algorithm is to be used.  Yahoo does not want to be forced to support signatures generated using the client secret - we don't even want this to be an option for the overwhelming majority of our APIs. Due to the way services are deployed at Yahoo, our security team feels that in general, having PR endpoints validate signatures computed using the client secret makes our overall system LESS secure - since we'd be forced to distribute client secrets to the PR endpoints. Distributing the client secret to the PR endpoints is very undesirable, since doing so requires that the PR endpoints have the same level of security as the AS.

Having a clean separation between the AS and the PR was one of the goals of Oauth-WRAP - and having the PR authenticate the client using the client secret violates this goal.

That being said, Yahoo does have private/internal APIs which require a very high level of security in which bearer tokens are not sufficient, and signatures using the AT secret aren't sufficient either - in these cases, signing the request with the client secret is probably the right way to go. Again - this should be up to the SP to determine that a signature is required, and how that signature is generated.

So what I'm trying to say is - yes there are cases where it's desirable to have stronger signatures than just signing with the AT secret - however I think that the cases in which signatures are required, and which signature algorithm is to be used should be entirely up to the SP.

I thought Allen clearly said that signing with the client secret won't work for Yahoo!?

Right - but he also said that they (i.e. Yahoo!) wouldn't need signatures at all. So I think we're good from the Yahoo! side of things.

Dirk.

Hi Dirk-

We at Yahoo would be very much against using the client secret for signing requests to Protected Resources, since this would require that the client secret be distributed to the PR endpoints. For security reasons, one of the design goals for WRAP was to keep the client secret a secret between only the AS and the Client - deliberately separating the authentication of the client (on the AS) from the serving of the protected resource.

>From your post, it's not quite clear what the disadvantage is with using the Access Token secret for generating signatures.

(forgive me if this was already discussed today - I was very zonked out after 3 days of IIW)

Thanks
Allen

Sorry, I didn't mean to turn this into a debate over whether we should have signatures. I think you guys stated your case clearly, and there are other use cases as well.

- you'd be ok using the client secret to sign instead of the token secret (I think I heard David say that that was ok),
- you'd be ok with a signature scheme that's sufficiently factored out of the rest of the spec that it might warrant it's own companion spec (I agree that this is getting close to bikeshed territory, so let's worry about this once we know what the signatures look like).

 Dirk.

 Dirk.

 --David

 Dirk.

Allen

<ATT00001..txt>

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

---

From: Andrew Arnott <[email-masked]>
Date: Sat, 29 May 2010 05:21:08 -0700

Hi Dirk,

If you eradicated access token secrets in favor of signing with client
secrets, how would installed apps, where the client secret is worthless and
usually blank, authenticate/sign their own requests?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

---

From: Andrew Arnott <[email-masked]>
Date: Sat, 29 May 2010 18:27:42 -0700

Perhaps we can say that installed client apps can have client secrets after
all, by calling the authorization server and asking for a new client_id and
client_secret assignment for that particular app-install.

Any thoughts on that?

On Sat, May 29, 2010 at 5:21 AM, Andrew Arnott <[email-masked]>wrote:

>> easier to implement

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 30 May 2010 10:45:24 +0200

what is the advantage in comparison to a token secret?

How do you want to propagate the client_id and secret to the resource  
servers?

regrards,
Torsten.

Am 30.05.2010 um 03:27 schrieb Andrew Arnott <[email-masked]>:

> Perhaps we can say that installed client apps can have client  
> secrets after all, by calling the authorization server and asking  
> for a new client_id and client_secret assignment for that particular  
> app-install.
>
> Any thoughts on that?
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the  
> death your right to say it." - S. G. Tallentyre
>
>
> On Sat, May 29, 2010 at 5:21 AM, Andrew Arnott  
> <[email-masked]> wrote:
> Hi Dirk,
>
> If you eradicated access token secrets in favor of signing with  
> client secrets, how would installed apps, where the client secret is  
> worthless and usually blank, authenticate/sign their own requests?
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the  
> death your right to say it." - S. G. Tallentyre
>
>
> at today's interim meeting, we were discussing Brian Eaton's  
> proposal for OAuth signatures. He was proposing a mechanism that  
> would (1) do away with base string canonicalization, (2) allow for  
> symmetric and public keys, and (3) allow for extensibility.
>
> OAuth 2 signing mechanism, one which is orthogonal to Brian's  
> proposal (i.e., it would work both with the signing mechanism in the  
> current spec, as well as with Brian's signature mechanism). The goal  
> of my proposal is twofold:
>
> - it separates out the mechanisms for delegated authorization and  
> for integrity protection into two independent pieces, which can be  
> put together by Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> "Servers may require that requests be authenticated by the Client,  
> so that presentation of the access token alone is not sufficient to  
> - Non-repudiation: high-security deployments may require that  
> requests be authenticated (signed) in a non-repudiateable way[1]
> access tokens may leak.
> - End-to-end-integrity: even if SSL _is_ used, network  
> infrastructure may strip SSL protection before the request reaches  
> the protected resource. The protected resource, however, may require  
> end-to-end integrity.
>
> client secret instead of the access token secret). Eventually,  
> instead of Section 5.3, we may have Brian's new signature scheme  
> section here, which would add the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>

---

From: Andrew Arnott <[email-masked]>
Date: Sun, 30 May 2010 09:45:21 -0700

The advantage over using token secrets as it seems to me is that neither
auth server nor resource server need to store any issued access tokens
because they could be self-describing and signed.  By having token secrets I
think storing every issued token at the auth server or resource server side
is almost unavoidable.  I say "almost" because theoretically the token
secret could be encrypted and included in the token itself, such that only
the auth/resource server could decrypt the secret, then use that secret to
verify the signature.  This is likely more trouble than it's worth for some
applications.

I don't have a solution to the "avoid sharing client secret with resource
servers" problem.  Some good points were made I think in this thread about
how that would need to be solved.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

On Sun, May 30, 2010 at 1:45 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> On Sat, May 29, 2010 at 5:21 AM, Andrew Arnott < <[email-masked]>
> [email-masked]> wrote:
>
>> Hi Dirk,
>>
>> On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz < <[email-masked]>
>> [email-masked]> wrote:
>>
>>> Hi guys,
>>>
>>>  <[email-masked]>[email-masked]
>>>  <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 30 May 2010 20:55:42 +0200

Encrypting the token secret in self-contained tokens is the obvious 
solution, from my point of view. That's the way such things are handled 
in Kerberos.

Regarding client secrets: One of the major obstacles when using OAuth 
1.0 in large deployments is the need for sharing client secrets between 
authz server and resource server. Overcoming that obstacle was an 
important requirement for OAuth2 from the beginning, expressed by a lot 
of people.

If you want to use client secrets (or privat keys) for the purpose, 
that's fine with me - as long as token secrets are supported as an 
alternative way of signing token-authorized requests.

regards,
Torsten.

Am 30.05.2010 18:45, schrieb Andrew Arnott:
> The advantage over using token secrets as it seems to me is that 
> neither auth server nor resource server need to store any issued 
> access tokens because they could be self-describing and signed.  By 
> having token secrets I think storing every issued token at the auth 
> server or resource server side is almost unavoidable.  I say "almost" 
> because theoretically the token secret could be encrypted and included 
> in the token itself, such that only the auth/resource server could 
> decrypt the secret, then use that secret to verify the signature.  
> This is likely more trouble than it's worth for some applications.
>
> I don't have a solution to the "avoid sharing client secret with 
> resource servers" problem.  Some good points were made I think in this 
> thread about how that would need to be solved.
> --
> Andrew Arnott
> On Sun, May 30, 2010 at 1:45 AM, Torsten Lodderstedt 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     How do you want to propagate the client_id and secret to the
>     resource servers?
>
>     regrards,
>     Torsten.
>
>
>     Am 30.05.2010 um 03:27 schrieb Andrew Arnott
>     <[email-masked] <mailto:[email-masked]>>:
>
>>     for a new client_id and client_secret assignment for that
>>     particular app-install.
>>
>>     Any thoughts on that?
>>     --
>>     Andrew Arnott
>>     "I [may] not agree with what you have to say, but I'll defend to
>>     the death your right to say it." - S. G. Tallentyre
>>
>>
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         Hi Dirk,
>>
>>         If you eradicated access token secrets in favor of signing
>>         with client secrets, how would installed apps, where the
>>         client secret is worthless and usually blank,
>>         authenticate/sign their own requests?
>>
>>         --
>>         Andrew Arnott
>>         "I [may] not agree with what you have to say, but I'll defend
>>         to the death your right to say it." - S. G. Tallentyre
>>
>>
>>         On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz
>>             at today's interim meeting, we were discussing Brian
>>             Eaton's proposal for OAuth signatures. He was proposing a
>>             mechanism that would (1) do away with base string
>>             canonicalization, (2) allow for symmetric and public
>>             keys, and (3) allow for extensibility.
>>
>>             He got homework from the group to prove the feasibility
>>             of his proposal by showing a couple of implementations.
>>
>>             In this post, I would like to introduce another
>>             improvement of the OAuth 2 signing mechanism, one which
>>             is orthogonal to Brian's proposal (i.e., it would work
>>             both with the signing mechanism in the current spec, as
>>             well as with Brian's signature mechanism). The goal of my
>>             proposal is twofold:
>>
>>             - it separates out the mechanisms for delegated
>>             authorization and for integrity protection into two
>>             independent pieces, which can be put together by Servers
>>             and/or Clients like LEGO blocks.
>>
>>             Summary:
>>
>>             - remove all parts of the spec that are of the kind "if
>>             bearer_token then X, else Y", and replace them with X.
>>             - delete section 5.3
>>             "Servers may require that requests be authenticated by
>>             the Client, so that presentation of the access token
>>             alone is not sufficient to access a Protected Resource.
>>              This has several use cases, including, but not limited
>>             to, the following:
>>
>>             - Non-repudiation: high-security deployments may require
>>             that requests be authenticated (signed) in a
>>             non-repudiateable way[1]
>>             infrastructure may strip SSL protection before the
>>             request reaches the protected resource. The protected
>>             resource, however, may require end-to-end integrity.
>>
>>             If the Server requires that the Client authenticate PR
>>             access requests, then the Client uses the following
>>             mechanism to sign their HTTP requests: [...]"
>>
>>             Then, we basically drop the old Section 5.3 here (except
>>             we use the client secret instead of the access token
>>             secret). Eventually, instead of Section 5.3, we may have
>>             Brian's new signature scheme section here, which would
>>             add the option of public-key crypto[1], etc.
>>
>>             What do you guys think?
>>
>>             Dirk.
>>
>>             [1] Technically speaking, the goal of non-repudiation can
>>             only be achieved once we have public-key crypto.
>>
>>

---

From: Brian Eaton <[email-masked]>
Date: Sun, 30 May 2010 14:41:39 -0700

On Sun, May 30, 2010 at 11:55 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> Regarding client secrets: One of the major obstacles when using OAuth 1.0 in
> large deployments is the need for sharing client secrets between authz
> server and resource server. Overcoming that obstacle was an important
> requirement for OAuth2 from the beginning, expressed by a lot of people.

There are actually a bunch of fundamentally conflicting requirements
for signatures from the various folks contributing to this working
group.

- no shared secrets with protected resources at all

- no permanent shared secrets with protected resources

- no shared secrets with clients

- allow access tokens to be used by multiple clients without sharing
consumer secrets

- don't allow access tokens to be shared by multiple clients

- don't use public key, because it's slow

- use public key, because it makes key distribution easier

- don't use cryptography at all, because it's too complicated

- don't use bearer tokens at all, because they might leak

- keep access tokens short

- encode lots of information in the access token

I'm sure I'm forgetting some.

For the record, I think *every single one* of those requirements makes
sense in certain contexts.

I'm pretty sure we're going to be able to agree on the cryptographic
primitives without too much trouble.

But we're going to have to split out profiles to deal with the
different key distribution challenges.

Cheers,
Brian

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 31 May 2010 07:08:20 +0200

sounds reasonable

Are your working on the cryptographic primitives and such profiles?

regards,
Torsten.

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 31 May 2010 15:58:20 +1000

Brian,

> sense in certain contexts.

I agree.

>... we're going to have to split out profiles to deal with the

Instead of starting with profiles, I think a key to addressing this issue is to make the token response format richer. It should tell the client app all it needs to know to authenticate its calls to protected resources. From a token response, a client app should know this particular service’s requirements: bearer token / client secret / token secret; shared secret / public key; short-term / permanent; ....

My mental model of the token response has it performing two tasks:
1. Indicating how to authenticate requests to protected resources -- much like a WWW-Authenticate response header for a "normal" authentication scheme (without user delegation).
2. Provide all or some of the values necessary to make those authenticated requests.

The token response should include the name of the HTTP authentication scheme that will be used to access protected resources.
Example: { "scheme":"BASIC" ...} or {"scheme":"Token" ...}

It makes it fairly obvious how to integrate other auth schemes with OAuth: just include the parameters from that scheme’s WWW-Authenticate header in a token response.

I quite like the idea of indicating whether subsequent requests are signed with the client’s secret or a token secret by simply omitting or including such a secret in the token response.
[This does assume that knowing the "scheme" is sufficient to determine if a secret is required, which is one more reason why reusing "Token" for bearer, MAC and public-key operations is a poor design.]
A (less desirable) alternative is a specific "client_auth":[TRUE|FALSE] parameter in a token response.

--
James Manger

---

From: "William Mills" <[email-masked]>
Date: Mon, 31 May 2010 20:18:26 -0700

In the client apps case you use bearer tokens.

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andrew Arnott
	Sent: Saturday, May 29, 2010 5:21 AM
	To: Dirk Balfanz
	Cc: OAuth WG
	Subject: Re: [OAUTH-WG] proposal for factoring out request
signing in OAuth 2

	Hi Dirk,

	
	On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz
<[email-masked]> wrote:

		Hi guys,  

		at today's interim meeting, we were discussing Brian
Eaton's proposal for OAuth signatures. He was proposing a mechanism that
would (1) do away with base string canonicalization, (2) allow for
symmetric and public keys, and (3) allow for extensibility. 

		In this post, I would like to introduce another
improvement of the OAuth 2 signing mechanism, one which is orthogonal to
Brian's proposal (i.e., it would work both with the signing mechanism in
the current spec, as well as with Brian's signature mechanism). The goal
of my proposal is twofold:

		- it simplifies the spec. It will become more readable
and therefore easier to implement
		- it separates out the mechanisms for delegated
authorization and for integrity protection into two independent pieces,
which can be put together by Servers and/or Clients like LEGO blocks.

		Summary:

		- use the client secret instead of the token secret for
signing PR access requests.

		- remove all references to access tokens that are not
bearer tokens from the spec.
		- stop calling the access tokens "bearer tokens". Call
them just "access tokens". 
		- remove all references to token secrets from the spec
		- remove all parts of the spec that are of the kind "if
bearer_token then X, else Y", and replace them with X.
		- delete section 5.3
		- add a section called "Request Authentication" that
goes something like this:

		"Servers may require that requests be authenticated by
the Client, so that presentation of the access token alone is not
sufficient to access a Protected Resource.  This has several use cases,
including, but not limited to, the following:

		- Non-repudiation: high-security deployments may require
that requests be authenticated (signed) in a non-repudiateable way[1]
		- Access to protected resources is not protected by SSL,
so that access tokens may leak. 
		- End-to-end-integrity: even if SSL _is_ used, network
infrastructure may strip SSL protection before the request reaches the
protected resource. The protected resource, however, may require
end-to-end integrity.

		If the Server requires that the Client authenticate PR
access requests, then the Client uses the following mechanism to sign
their HTTP requests: [...]"

		Then, we basically drop the old Section 5.3 here (except
we use the client secret instead of the access token secret).
Eventually, instead of Section 5.3, we may have Brian's new signature
scheme section here, which would add the option of public-key crypto[1],
etc.

		What do you guys think?

		Dirk.

		[1] Technically speaking, the goal of non-repudiation
can only be achieved once we have public-key crypto.

---

From: Dirk Balfanz <[email-masked]>
Date: Mon, 31 May 2010 22:41:46 -0700

> client_secret assignment for that particular app-install.

Maybe. Do we have an example of somebody who needs to do that? (At Google we
would probably just use SSL, or if that's not possible make the access token
very short-lived, but stick with bearer tokens.)

Dirk.