+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 on 25/09/2010 00:26 -1 on requiring it to be part of core OAuth2. Reasoning: It won't be a MUST or even SHOULD requirement for either client or server, so adding it later does not affect interop. The actual schedule to finalize the signature mechanism should not be affected either way -- it's fine for a WG to produce 2 or more RFCs if that's the right thing to do. (If there were consensus today on what exactly the signing mechanism should be I'd think differently, but I don't believe there is.) Caveat: If there were consensus that OAuth 2 should simply adopt the OAuth 1.0a signature mechanism today, I'd be okay with that, just because there is some proven code out there. This is of course a trade-off. My bias: I really want us to stabilize what has been spec'd so far and move forward with that while additional work happens. There are already multiple mutually implementations of "OAuth2" floating around and I'd rather resolve that quickly. -- John Panzer / Google jpan...@google.com / abstractioneer.org / @jpanzer On Thu, Sep 23, 2010 at 6:43 PM, Eran Hammer-Lahav <e...@hueniverse.com> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
