+1 for basic signature support
there is a need to protect end-users from token abuse by rogue resource
servers (see
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5, paragraph
3). Signatures based on a token secret is one way to prevent this kind
of attack.
Signature mechanisms
+1
2010/9/24 Eran Hammer-Lahav :
> Since much of this recent debate was done off list, I'd like to ask people
> to simply express their support or objection to including a basic signature
> feature in the core spec, in line with the 1.0a signature approach.
>
> This is not a vote, just taking the
+1
I am agnostic as to whether this means we define the signatures within
the spec or just reference/profile some other work. The fewer number of
signature algorithms we have to implement the better:)
George
On 9/23/10 9:43 PM, Eran Hammer-Lahav wrote:
Since much of this recent debate was
I would like to see the signatures stay in a separate spec, but to be
worked on and released along side of the core spec.
In fact, I think that there's more than one kind of "signature" that can
be used with the OAuth token mechanisms. At IIW East, we walked through
several use cases that called
> If it wasn’t clear, the reason why I am back at fighting for this
> after taking a break for a few months, is based on the recent positive
> experience from the Twitter migration. To me, it completely voids the
> arguments that normalization on the client side is too hard.
I wholeheartedly disag
Yeah, that is true. One of my reasons for bringing this up was in
consideration of proposing a similar simplification around client
authentication. But clearly client authn and grants can and will be
presented together in the same request. I was aware of the potential
for name conflicts but didn
I think that any signature method that we end up using needs to rely
less on magic and anecdote and more on explicit declaration.
This is certainly correct ...
I think
that Brian Eaton's approach of sending the bare string that was
signed,
which was also a JSON element that could be parsed
> > I think that any signature method that we end up using needs to rely
> > less on magic and anecdote and more on explicit declaration.
>
> This is certainly correct ...
>
>
> > I think
> > that Brian Eaton's approach of sending the bare string that was
> > signed,
> > which was also a JSON
Yes, there is certainly a risk if someone just checks the signature
and
does not verify the content of the message. This is a bad
implementation
of an authorization system, to be sure, and it's an issue that people
need to be aware of. But simply signing metadata doesn't completely
solve the p
Validating the signed data delivered with the request is as much magic as the
current 1.0 approach. Go write the validation rules and see.
I'm getting really tired of this argument because it is not grounded in
reality. Any attempt to compare the HTTP request to what was signed, whether it
is s
Richard,
I'm a bit confused because the made-up example you give below is,
essentially, what Magic Signatures does. The algorithm you present is
basically the correct one IMHO. Are you assuming that the recipient is
_also_ using the HTTP-level method and URL path for some important security
dec
Maybe I've misunderstood the Magic Signatures proposal. I thought
that the MagicSig blob actually contained the data that was signed, so
that step (3) below would be unnecessary. (Note that the object in
Step 2 has only field *names*, not *values*.) Including the data is
the part of that
On Fri, Sep 24, 2010 at 9:06 AM, Eran Hammer-Lahav wrote:
> Validating the signed data delivered with the request is as much magic as
> the current 1.0 approach. Go write the validation rules and see.
>
Done that (for the specific case of Salmon). The only trick is to write the
code so that if t
Ah ok, I misread your field names as field values :).
Of course recipients can always choose to ignore the result of verifying
signatures (or not verify them at all) no matter what scheme you use.
Note that Magic Signatures is unabashedly an envelope, and well written
libraries make it hard to sh
On Thu, Sep 23, 2010 at 7:59 PM, Richard L. Barnes wrote:
> Basically, this argument comes down to which validation pattern you prefer.
>
> OPTION 1:
> 0. Input = object + signature
> 1. Verify match between object data and HTTP fields
> 2. Verify signature over the object
>
> OPTION 2:
> 0. Inpu
I hope I am not causing the temperature of the group to rise dangerously
by "voting" in support (a.k.a. +1).
Igor
Eran Hammer-Lahav wrote:
Since much of this recent debate was done off list, I'd like to ask people
to simply express their support or objection to including a basic signature
fea
Then there's the question of checking to see if the data in the
envelope is consistent with data outside the envelope. A good way
to do this is to ignore the data outside the envelope and only use
the verified, enveloped data.
This is precisely the problem. But think about what "only usin
I think it's more robust to verify than to generate. In option 2,
you have to "guess" what the signer actually signed. To be fair, you
have pretty good signals, like the HTTP request line, the Host:
header, etc., but in the end, you don't _know_ that the signer
really saw the same thing whe
On Fri, Sep 24, 2010 at 10:08 AM, Richard L. Barnes wrote:
> I think it's more robust to verify than to generate. In option 2, you have
>> to "guess" what the signer actually signed. To be fair, you have pretty good
>> signals, like the HTTP request line, the Host: header, etc., but in the end,
>
Most developers will do one of two things:
1. Completely ignore the HTTP request and just look at the signed data.
2. Come up with some simple rules to normalize both the request URI and signed
data and compare them to make sure they are the same.
Why is this bad?
- This proposal recreates SOAP
+1 for signature support in the core spec (which may look like normative
pointers out to a separate spec module if it turns out there's wider usage for
that module beyond OAuth).
Eve
On 23 Sep 2010, at 6:43 PM, Eran Hammer-Lahav wrote:
> Since much of this recent debate was done off li
Perhaps this is picking nits but I want to clarify my opinion: I'm fine
if the core spec *mentions* signatures, I just don't want it to *define*
them. I'm perfectly happy with a section on "if you want to do signing,
here's a way to do signing", but I want that way to be defined and
described elsew
+1 for adding it in to the core spec..
Thanks,
RD
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eve Maler
Sent: Friday, September 24, 2010 1:38 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Basic signature support in the core
s
My understanding of Eran's article
(http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/)
is that Eran believes that bearer tokens are not good enough as a security
mechanism because they allow for replay attacks in discovery style scenarios.
He then, if I understood t
Yaron,
You have referenced the SAML browser SSO protocol (POST profile) in
your blog posting, and correctly observed that the same problem would
manifest itself there as well.
As a counter-measure, the SAML POST profile explicitly requires that the
target (destination) URL or similar ident
-1 on requiring it to be part of core OAuth2. Reasoning: It won't be a MUST
or even SHOULD requirement for either client or server, so adding it later
does not affect interop. The actual schedule to finalize the signature
mechanism should not be affected either way -- it's fine for a WG to produc
+1 on core
On Thu, Sep 23, 2010 at 6:43 PM, Eran Hammer-Lahav wrote:
> Since much of this recent debate was done off list, I'd like to ask people
> to simply express their support or objection to including a basic signature
> feature in the core spec, in line with the 1.0a signature approach.
>
>
That's a confusing answer Eve. Is it in the spec or pointed to from the spec?
I think there is consensus that there are enough use cases that signatures need
to be spec'ed -- the question is if the signature spec is in core or a separate
spec.
For people that don't need signatures, having them
-1 in core
+1 to being referenced in core and being a separate document
On 2010-09-23, at 6:43 PM, Eran Hammer-Lahav wrote:
> Since much of this recent debate was done off list, I'd like to ask people
> to simply express their support or objection to including a basic signature
> feature in the
+1 on referencing separate spec from the core.
-1 for actually defining the sig inside the core.
=nat @ Tokyo via iPhone
On 2010/09/24, at 10:43, Eran Hammer-Lahav wrote:
> Since much of this recent debate was done off list, I'd like to ask people
> to simply express their support or objectio
OAuth 2.0 is far from being published as an RFC. I estimate it is at least 6
months away from reaching final IESG approval, if not a year. This is mostly
due to a significant effort needed in writing and reviewing the security
considerations section which so far has received no attention. We can
Most developers don't know if they need signatures! By putting them elsewhere
we will be promoting the bearer token approve as the default choice and that's
unacceptable to me. It is promoting a specific security compromise (for
developer ease) that is far from industry consensus.
I can make th
I'm happy to do that. But I will be breaking the spec into more than two parts.
Basically, I will be creating a version that does not force anyone to read
anything they might not care about. Clearly, we shouldn't based editorial
decisions on what you want to read :-)
EHL
On 9/24/10 5:21 PM, "
These are my two:
1. Remove the need to rely solely on HTTPS
There are plenty of cases where people can't or don't want to use HTTPS.
Clearly, the web is not all HTTPS and OAuth should be useful on the entire web.
We are not going to settle the long debate over the cost or speed of using
HTTPS
wrt. developers knowing what they need => I think the AS / PR will tell
developers if they need to use signatures, or if they need to use HTTPS, or if
they need to use assertions.
Sorry for including more than one topic in my email :: my main point was that I
was confused by what Eve was propo
I don't follow your logic ... or perhaps I don't see why the spec needs to be
written in more than two parts.
For example, the current spec does not specify the format of the token -- which
keeps it simpler and straight forward. There are separate draft specs for
standardizing the token. Simila
36 matches
Mail list logo
