> 1. Why are you here? What are you trying to solve that is not already > addressed by existing specifications (OAuth 1.0a, WRAP, etc)?
I would like to see OAuth 1.0 extended to support more methods for obtaining tokens to optimize usability for non-web-based clients. I also want to clean the overall architecture and simplify parts of the spec that were originally designed to work on very limited platforms. I am also concerned about the security implications of WRAP adoption as currently written. > 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? > Something else? Strictly from an editor's perspective, OAuth 1.0a (as documented in the recently approved draft-hammer-oauth RFC) offers the best narrative to build on. The document has gone through many revisions and reflects over a year of work on top of the original OAuth specification. It would be easier to add the new methods of obtaining a token into OAuth, than to rewrite WRAP to reach the same level of document maturity. > 3. If we start from draft-hammer-oauth, what needs to change to turn it into > OAuth 2.0? To start with, adding all the new flows in WRAP to make it feature complete. The authentication section needs to be cleaned up and incorporate a new message format for signing (similar to Brian's proposal), as well as remove the need to use the client credentials for accessing resources. It also needs to replace PLAINTEXT with a simpler, cleaner bearer token solution that does not require reading the entire specification to implement. > 4. If we start from draft-hardt-oauth, what needs to change to turn it into > OAuth 2.0? The primary issues are similar to the OAuth specification in how parameters are sent, named, as well as lacking any support for signatures. Ignoring the early stage of the draft, the document needs more clarity in its terminology. It uses an architecture that is not fully explained or specified, leaving too much for the implementer to figure out. For example, WRAP doesn't directly support the separation of the token issuer from the resource server because it doesn't explain how such a decoupling can be implemented in practice. > 5. Do you think the approach of working first on 'how to use a token' and > then on 'how to get a token' is right? I am not sure anymore. It has not worked so far, and it seems people are not motivated to engage this effort because they don't see how all the pieces come together. It looks like taking one of the two specs (1.0a or WRAP) and starting to revise it frequently until it is feature complete is going to get people more engaged. > 6. Should we go back to working on a single specification? Yes. Same as the previous answer. I am still not sure if we should end up publishing a single specification, but when we are done, we can ask the opposite question if the 'how to use a token' section is more useful on its own. > 7. Do you think the protocol should include a signature-based authentication > scheme? Yes. I agree that a bearer token over SSL/TLS offers more than an HMAC-based signature over non-secure channel. I personally don't see much value in the HMAC signature because any token-issuing server will have to support SSL/TLS for sending tokens in the first place. So the argument that we need to support servers without SSL/TLS is false (note that draft-hammer-oauth as approved requires SSL/TLS for all plaintext secrets). I don't know enough to say if the argument that HMAC is cheaper/faster/easier than always using SSL/TLS is true or not. What I am interested in is support for asymmetric secrets because that's the only way I know to avoid the need for client registration, without giving up completely on client identity verification. But since this requires a signature process, defining an HMAC option becomes just a matter of a few more lines. In other words, if we support an RSA-SHA1-like method, we might as well also support HMAC. I posted my use case for this separately. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
