Am 27.09.2010 19:11, schrieb Anthony Nadalin:
What is needed is needed is the security considerations section complete, I
don't think that the signature specification has to be in the core to be
complete, there are previsions to use SSL, if one needs to go beyond this then
a reference to the signature specification would be in the security
considerations section. The separation allows for an OAuth independent solution
that would/could cover message and token encryption and signing. If signature
is going to be an extension point
I don't understand why signing tokens and signing message shall be
solved with the same solution.
In my opinion, tokens are opaque to any client and are just passed
through as an uninterpreted string from authorization server (AS) to the
resource server (RS) via the client. So the OAuth spec does not
necessarily have to standardize their format (incl. signatures) in order
to facilitate protocol interoperability. AS and RS just have to use the
same format. Since both have a thight relationship that should not be a
problem. If one like it can use an existing formats like SAML assertions
or SWT.
That's completely different from message signing. Here all parties are
involved. So any client accessing a pair of AS and RS has to know how to
sign a message in order to prove legitimate token ownership and/or
protect the message from modifications.
regards,
Torsten.
why have any in the core? Already we would have questions from our customers on
the use of HMAC-SHA1. According to Hannes the security considerations section
is underway and will explain what signatures provide and what they do not
provide and let the implementer choose what scenarios they are implementing for
and the risk factors of those scenarios and if signatures are needed or just
SSL.
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Igor
Faynberg
Sent: Monday, September 27, 2010 9:42 AM
To: Eve Maler
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Basic signature support in the core specification
I think Torsten's previous comment explains it well: We cannot expect approval
of the core, if security is not sufficiently addressed. I also agree that it
cannot be addressed without the signature mechanism clearly specified.
Therefore, if anything is going to delay the core, it is the absence of the
signature specification. A dangling reference to work in progress won't help;
the referred spec must be there.
But if both the OAuth signatures and the OAuth core specifications are complete
and going for approval at the same time, why not actually have them in the same
spec, especially given that we experts who have agreed working on this and ARE
working on this?
Igor
Eve Maler wrote:
It seems like you figured it out pretty quickly, given the message you
sent immediately after. :-)
Referencing another spec from the core spec using normative text is
effectively "including it by reference". I meant that I'm sympathetic
(+1) to signaling in core OAuth that signatures are to be considered
an integral part of it, and that if it makes sense to do so by
pointing to a spec module that is pointable-to by other specs that are
not OAuth, that's fine (call it a soft -1 to including the signature
details directly in the core OAuth spec).
Eve
On 24 Sep 2010, at 10:39 PM, Dick Hardt wrote:
wrt. developers knowing what they need => I think the AS / PR will
tell developers if they need to use signatures, or if they need to
use HTTPS, or if they need to use assertions.
Sorry for including more than one topic in my email :: my main point
was that I was confused by what Eve was proposing.
-- Dick
On 2010-09-24, at 7:23 PM, Eran Hammer-Lahav wrote:
Most developers don't know if they need signatures! By putting them
elsewhere we will be promoting the bearer token approve as the
default choice and that's unacceptable to me. It is promoting a
specific security compromise (for developer ease) that is far from
industry consensus.
I can make the same arguments about assertions. Or any single
profile. Or any client credentials type. The bits that are in are
based solely on a team effort in trying to accommodate as many
people as possible. Seems like those opposed signatures got
everything they want, don't really care about others, and are ready
to call it a day.
EHL
On 9/24/10 5:20 PM, "Dick Hardt"<dick.ha...@gmail.com
<x-msg://12/dick.ha...@gmail.com>> wrote:
That's a confusing answer Eve. Is it in the spec or pointed to
from the spec?
I think there is consensus that there are enough use cases that
signatures need to be spec'ed -- the question is if the
signature spec is in core or a separate spec.
For people that don't need signatures, having them separate
keeps the core spec simpler. Having a separate spec enables
other groups to reuse the signature mechanism without confusing
their readers with the rest of the OAuth spec.
On 2010-09-24, at 1:37 PM, Eve Maler wrote:
> +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 list, I'd like
to ask people
>> to simply express their support or objection to including a
basic signature
>> feature in the core spec, in line with the 1.0a signature
approach.
>>
>> This is not a vote, just taking the temperature of the group.
>>
>> EHL
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org<x-msg://12/OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> Eve Maler
http://www.xmlgrrl.com/blog
> +1 425 345 6756
http://www.twitter.com/xmlgrrl
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org<x-msg://12/OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
----------------------------------------------------------------------
--
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
