I would also be happy with the core only dealing with *getting* a token, and moving all text about *using* a token to other documents. This will produce three parts:
1. Getting a document 2. Using bearer tokens 3. Using cryptographic tokens Part 3 can include both the JSON token and a 1.0a HMAC-SHA-1 solution (unless we can solve that disagreement which I highly doubt). Or part 3 can be just the signature framework. With such a setup, I'm happy to close part 1 and 2 immediately and move them along (only hold final RFC publication until part 3 is ready). EHL From: [email protected] [mailto:[email protected]] On Behalf Of Phil Hunt Sent: Monday, September 27, 2010 9:52 AM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: [email protected] Subject: Re: [OAUTH-WG] Document Management Issue (Signatures) I think it would also help with handling revisions over time. Changes to signature specifications, etc over time, won't impact the core specification -- keeping it stable and well understood. Maybe a compromise is to include the 1.0a stuff in the core spec as "legacy" (since it was in the 1.0 core), but reference a normative external signature extension specification document for 2.0 on. Phil [email protected]<mailto:[email protected]> On 2010-09-27, at 9:43 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Hi all I wonder whether the question of "signature in the main specification or in a separate document" does not really matter. It is purely a matter of document management style. The important question is whether there will be a **mandatory to implement** or **mandatory to use** someone in the document set. Mandatory to use is typically hard to enforce unless there is only one approach possible. This does not seem to be the case. So, everything then boils down to the question: What is mandatory to implement? (in this specific case with regard to security) Ciao Hannes _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
