Re: [OAUTH-WG] why are we signing?

[John Panzer <[e-mail]>]

I think that https plus bearer token is sufficient for 90% of use
cases.  I haven't heard a first principles argument otherwise.  If for
no other reason than the record, could the proponents of signing
explain why bearer token over TLS will not meet their needs?

On Thursday, November 12, 2009, Eran Hammer-Lahav <[e-mail]> wrote:
> As a matter of process, I would suggest looking at what the 1.0 HMAC-SHA1 method signs, and discuss if it is where we should be. We are working with an existing draft and should structure our discussions as feedback to that point of reference. This doesn't limit the conclusion in any way, and is how this WG has been chartered.
>
> EHL
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Brian Eaton
>> Sent: Wednesday, November 11, 2009 5:54 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [OAUTH-WG] why are we signing?
>>
>> So we've got at least five different use cases for signing requests
>> with the oauth access token and token secret.
>>
>> Sweet.
>>
>> The downside to the use cases is that they all have incompatible
>> signature base strings.  I'd like to see us come up with something so
>> that we don't have to reinvent the base string again for every single
>> use case.
>>
>> Cheers,
>> Brian
>>
>> On Wed, Nov 11, 2009 at 5:49 PM,  <[e-mail]> wrote:
>> >
>> > On Mon, Nov 9, 2009 at 6:28 AM, John Kemp <[e-mail]> wrote:
>> >> If we are only interested in i) [authenticating the entity] then
>> > signing any piece of the message might
>> >> be sufficient. If we are interested in ii) [binding the signature to
>> > the message] (or some other security property)
>> >> then we will need to identify which pieces of the message we want to
>> > provide
>> >> that, or other, security properties for.
>> >
>> >> Brian Eaton wrote:
>> >> OK, let me try to summarize what I've heard on this thread about the
>> >> different use-cases for message signing:
>> >>
>> >> - sign the HTTP request
>> >>   Used to prevent MITM from replaying token to a different URL.
>>  Also
>> >> limits the replay attack window to minutes instead of hours.
>> >>
>> >> - sign various other parts of the message
>> >>   DKIM: signs various message headers
>> >>   SIP: unspecified, just says "relevant parts of SIP request"
>> > Hannes Tschofenig suggested handle SIP messages the way described in
>> RfC
>> > 4474 (SIP identity). It lists the parts of a SIP messsage that need
>> to
>> > be protected.
>> >
>> > Wolfgang
>> >
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
--
John Panzer / Google
[e-mail] / abstractioneer.org / @jpanzer