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
