> 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)?
I am here because delegation is really important functionality for the web. I want delegation functionality that can work even when a client has not been pre-registered with a service. I want delegation functionality that fits well with the style of the web (particularly HTTP). I want a logically clean protocol for the best chance of being applicable to a variety of scenarios (eg decouple authz and authn, minimal spots for service-specific "additional params"). > 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting > point? Something else? WRAP is probably a better starting point. > 3. If we start from draft-hammer-oauth, what needs to change to turn it > into OAuth 2.0? Remove the request signing mechanisms. > 4. If we start from draft-hardt-oauth, what needs to change to turn it > into OAuth 2.0? Separate user/client/server delegation from client/server credential refresh -- I am not sure they are as related as WRAP makes out. Better 401 Unauthorized WWW-Authenticate responses (not just "WRAP" for everything). "Discovery" (within direct HTTP request/response flow): of redirect URIs, of authentication mechanisms, of the domains where a token can be used... > 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? No. As long as "how to get a token" can result in an authz token (& some metadata) or an id plus secret key (& some metadata) then any number of different approaches can be adopted for "how to use a token" -- and they can be chosen at any time, by anyone. It would be nice to have one simple "how to use a token" option specified up front -- ie a bearer token scheme -- so you can visualise a complete delegation flow. > 6. Should we go back to working on a single specification? No. A separate spec just for transmitting a bearer token would be useful (and short). > 7. Do you think the protocol should include a signature-based > authentication scheme? No. The delegation protocol should be capable of working with signature-based auth schemes. Any number of signature schemes can be defined separately if there is agreement on what to sign (URI, host, headers, body...), what to sign with (password, shared secret, public key crypto...), what security to offer (user auth, data origin auth, confidentiality, replay protection, with or without clocks, zero-knowledge proof...), what performance is important (latency, round trips, 1-pass...), and what operational security is possible (nonces, cleartext keys, short-term keys...) -- James Manger _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
