-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 <http://www.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 > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
