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
To be clear, I think signatures are important, and I think that standardizing
them would be really useful. One of the early complaints about OAuth 1.0 was
that the signature mechanism was different than the OpenID mechanism. Having a
standard signature mechanism in this space seems like a good t
My logic is that your suggested organization is based on your personal
preferences and what you consider core. If I applied my personal preference,
half of core would be elsewhere. My point is that deciding signatures is the
part belonging elsewhere is completely subjective to how important one
I was talking about AS / PR developers.
EHL
On 9/24/10 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 t
Am 25.09.2010 04:22, schrieb Eran Hammer-Lahav:
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 sect
+1 to having it in the core spec. I don't see how an optional section in
the spec will cause any confusion
+1 to John's suggestion below of starting with the OAuth 1.0a signature
mechanism. Why not put it in the spec and see what breaks or no longer
holds true
Mark McGloin
John Panzer wrote o
