Note there will be three documents not two. The suggested change does not address the issue that myself and others had raised with having signatures be in the core. The suggestion was that having signatures be a different spec made them reusable by other groups and enabled a more comprehensive signature specification. Having them in core made them OAuth specific.
I think there was consensus with those that had seen the advantage of a different signature spec that including the OAuth 1.0A signature mechanism in core and having a clear extension mechanism was a satisfactory direction. This enables alternative algorithms to be specified From what I have gathered, the only advantage to breaking it up is participants can "ignore" bearer tokens or signatures if they don't "value" one of those mechanisms. Personally, I think it is important that we all respect the various use cases rather than push one mechanism under the rug because it is not important to us. From what I understand of IETF process, we are striving for rough consensus. If there is not consensus that both bearer tokens and signatures are important, then the I think we need to have a break through in that issue rather than breaking up the document. As I have reflected on this proposal, I am now a strong -1 for the following reason: Deep understanding of the full flow and security implications of the full flow is critical to a successful implementation and deployment. As Eran keeps pointing out, understanding the security implications of bearer tokens (and conversely, of using signatures) is a critical security decision. Breaking the document up implies to the reader that not all sections need to be read. If they are not all read, then the reader will not have a complete understanding of the protocol, and hence not a complete understanding of the security implications. -- Dick On 2010-09-30, at 2:23 AM, Lukas Rosenstock wrote: > +1 > > While it's good to have one document, it's better to have two good documents > instead of one that we're unhappy with. > > There'll be "Implementer's Guides" and "Tutorials" later who will do the job > of explaining how to make sense of the two (which of course doesn't mean I'm > advocating specifications which are hard to understand without other > material). > > 2010/9/28 Eran Hammer-Lahav <[email protected]> > 1. Add a parameter to the token response to include an extensible token > scheme. > > > The default (if omitted) will be whatever the bearer token scheme is called. > This will allow the authorization server to return any token type it deems > appropriate, and for other specifications to define additional parameters > such as token_secret. Others can extend the token request endpoint by allow > the client to request a specific token scheme. > > > 2. Break the core specification into multiple parts. > > > Go back to the original working group consensus to break the document into > two parts: getting a token and using a token. Getting a token will include > everything from core expect for section 5. Section 5 will become a new > specification which will describe how to use a bearer token (replacing the > generic ‘OAuth’ scheme with something more descriptive like). > > > 3. Introduce two signature proposals in one or more documents, for the JSON > token and 1.0a-like method. > > > One, both, or none can become working group item. > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
