From: Anthony Nadalin <tonynad@microsoft.com>
To: "igor.faynberg@alcatel-lucent.com" <igor.faynberg@alcatel-lucent.com>,
 "Eve Maler" <eve@xmlgrrl.com>
Thread-Topic: [OAUTH-WG] Basic signature support in the core specification
Thread-Index: Actbiea9Kvc91oocXkChShLMRTSOPwA2RnCAAAfEaYAABE/hgAAG16IAACxyFIAAT0o2AAAOP0Cg
Date: Mon, 27 Sep 2010 17:11:09 +0000
Message-ID: <1990A18DEA6E97429CFD1B4D2C5DA7E70CB6FF@TK5EX14MBXC101.redmond.corp.microsoft.com>
References: <C8C2AB33.3AD38%eran@hueniverse.com>
 <BFD0447E-42BB-441F-A7B3-B0CFB0F6317B@gmail.com>
 <E0B0A685-4BA7-451B-B0DF-C0FC429595D1@xmlgrrl.com>
 <4CA0C96E.8090907@alcatel-lucent.com>
In-Reply-To: <4CA0C96E.8090907@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Basic signature support in the core specification
Precedence: list

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 c=
omplete, there are previsions to use SSL, if one needs to go beyond this th=
en a reference to the signature specification would be in the security cons=
iderations section. The separation allows for an OAuth independent solution=
 that would/could cover message and token encryption and signing. If signat=
ure is going to be an extension point 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 implemente=
r choose what scenarios they are implementing for and the risk factors of t=
hose scenarios and if signatures are needed or just SSL.

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of I=
gor 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 appro=
val of the core, if security is not sufficiently addressed. I also agree th=
at it cannot be addressed without the signature mechanism clearly specified=
. Therefore, if anything is going to delay the core, it is the absence of t=
he 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 comp=
lete 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=20
> sent immediately after. :-)
>
> Referencing another spec from the core spec using normative text is=20
> effectively "including it by reference". I meant that I'm sympathetic
> (+1) to signaling in core OAuth that signatures are to be considered=20
> an integral part of it, and that if it makes sense to do so by=20
> pointing to a spec module that is pointable-to by other specs that are=20
> not OAuth, that's fine (call it a soft -1 to including the signature=20
> 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 =3D> I think the AS / PR will=20
>> tell developers if they need to use signatures, or if they need to=20
>> use HTTPS, or if they need to use assertions.
>>
>> Sorry for including more than one topic in my email :: my main point=20
>> 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=20
>>> elsewhere we will be promoting the bearer token approve as the=20
>>> default choice and that's unacceptable to me. It is promoting a=20
>>> specific security compromise (for developer ease) that is far from=20
>>> industry consensus.
>>>
>>> I can make the same arguments about assertions. Or any single=20
>>> profile. Or any client credentials type. The bits that are in are=20
>>> based solely on a team effort in trying to accommodate as many=20
>>> people as possible. Seems like those opposed signatures got=20
>>> everything they want, don't really care about others, and are ready=20
>>> to call it a day.
>>>
>>> EHL
>>>
>>>
>>> On 9/24/10 5:20 PM, "Dick Hardt" <dick.hardt@gmail.com=20
>>> <x-msg://12/dick.hardt@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
>  =20
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth