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 <balf...@google.com
<mailto:balf...@google.com>> 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?
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
<record...@gmail.com <mailto:record...@gmail.com>> 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
<balf...@google.com <mailto:balf...@google.com>> 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.
Luke, Dave - would a separate signing spec be ok with you
guys?
Dirk.
On Tue, May 25, 2010 at 6:56 PM, Allen Tom
<a...@yahoo-inc.com <mailto:a...@yahoo-inc.com>> wrote:
+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."
<jric...@mitre.org <mailto:jric...@mitre.org>> 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: oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>
[oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>] On Behalf Of Dirk
> Balfanz [balf...@google.com
<mailto:balf...@google.com>]
> 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,
>
> 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.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<ATT00001..txt>
