On Thu, Feb 18, 2010 at 11:14 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > A few questions we should answer before moving forward. Considering *your* > use cases and reasons for being here: > > 1. Why are you here? What are you trying to solve that is not already > addressed by existing specifications (OAuth 1.0a, WRAP, etc)?
OAuth 1.0a already meets most of my needs, but I think that there is room for improvement, clarification, and simplification, especially around key/token/secret acquisition and management and around the PLAINTEXT method. > 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? > Something else? On the resource access side, OAuth 1.0a. WRAP does not address the signature methods at all, so I do not think it is a good starting point. On the access token acquisition side, the WRAP profile approach makes a lot of sense in that it acknowledges and takes on the complexity of acquiring a token in different scenarios. However, I think we would still need to define something which the different profiles are ... profiling ... so we probably need to start from OAuth 1.0a and add on the profiles. Perhaps it makes sense to publish the profiles as separate documents instead of as part of the main document, but I'd think they need to be developed in parallel. > 3. If we start from draft-hammer-oauth, what needs to change to turn it into > OAuth 2.0? I haven't gotten to thoroughly review the current draft, but from my point of view it looks pretty good from the resource access perspective. If replacing the entire PLAINTEXT flow with WRAP would make people happy, then I would be for that, but I don't see much difference between them. I think it really depends on what current implementations use WRAP (not sure about the number) vs. OAuth 1.0a PLAINTEXT (not many to my knowledge). > 4. If we start from draft-hardt-oauth, what needs to change to turn it into > OAuth 2.0? I haven't been able to review this draft in detail. I like the profiling approach to a certain extent, but the fact that it completely ignores the signature scenario (and thereby ignores the vast majority of OAuth deployments as far as I can tell) is extremely problematic when considering it as a starting point. > 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? Yes. I think that as long as we are agreed that a single access token is being used and that token is opaque to the client, then this approach makes sense. > 6. Should we go back to working on a single specification? I'm in the "no" camp, but mostly for logistical reasons. I have a hard time reading through a new draft of a specification that includes both pieces. It is worth noting that there was (IIRC) some confusion in the OAuth community, especially around signature calculation, that seemed to be caused by having both parts of the OAuth model in one document. People had a hard time understanding that the token acquisition flow and the resource request were very different animals. > 7. Do you think the protocol should include a signature-based authentication > scheme? Absolutely. It's worth noting that OAuth 1.0a had a PLAINTEXT method similar to WRAP. As far as I can tell, it would have been possible for WRAP to define its resource access method to be compatible with the OAuth 1.0a PLAINTEXT method. I only say this to point out that none of the main OAuth implementations support the PLAINTEXT method to my knowledge, even though they could have done so. I think there are a lot of reasons one would want to use a signature method over the PLAINTEXT method or WRAP (and there are a lot of reasons in the other direction). But this is just a survey, so that answer is plenty long enough :-) Ethan _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
