On 2/18/10 10:14 AM, Eran Hammer-Lahav wrote: > A few questions we should answer before moving forward.
Eran, I think those were good questions. I've summarized the list feedback so far below. I'm out of time for the moment, but will reply with some of my own thoughts soon... > Considering *your* use cases and reasons for being here: > > 1. Why are you here? Reasons include: - need to build applications on top of OAuth - interested in token-based infrastructures - interested in non-web applications - want to simplify the architecture - concerned about security issues - want an extension for passing around signed identity claims - want to build Internet-scale applications - seeking greater simplicity - see a need for a widespread authn/authz technology - concerned about fragmentation / care about open standards > What are you trying to solve that is not already addressed by > existing specifications (OAuth 1.0a, WRAP, etc)? Problems include: - 1.0a doesn't easily support distributed policy enforcement - there is a lot of potential beyond the use cases covered in 1.0a - need improved support for central authorization services - protected resource needs to know consumer key and secret (security issue) - should be an option to pass a bearer token over an encrypted channel - in some environments it is difficult to revoke access tokens - need support for asymmetric secrets to avoid client registration - OAuth 1.0a flow is too complex - too many round trips - doesn't support non-web use cases very well - need more pictures / flow diagrams to make it more readable - integrate better with OpenID - the problems depend on the use cases (define those first) - recursive delegation is undefined - optimize for the web - support more use cases than defined in 1.0a - clarify what we have in 1.0a > 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting > point? Something else? Both: 5 (take the best parts from each document) WRAP: 4 Either: 2 (just start with use cases!) OAuth 1.0a: 2 > 3. If we start from draft-hammer-oauth, what needs to change to turn > it into OAuth 2.0? - separation of token issuance (delegation) and request authentication - abstract token format w. concrete minimum supportable set - token usage profiles (e.g. bearer vs. symmetric key vs. asymmetric) - add the flows from WRAP - add a new message format for signing - don't require client credentials to access protected resources - replace PLAINTEXT with a simpler bearer token format or WRAP/TLS - better separation of authorization (get a token) from authentication (use a token) - remove signing requests - keep signing requests but simplify > 4. If we start from draft-hardt-oauth, what needs to change to turn > it into OAuth 2.0? - to support message signing, authorization servers should optionally issue token secrets - more clearly explain the architecture, especially how the token issuer can be separate from the resource server - improve security considerations - add non-PLAINTEXT use cases - separate user/client/server delegation from client/server credential refresh - better 401 Unauthorized WWW-Authenticate responses - discovery of redirect URIs, of authentication mechanisms, of the domains where a token can be used - need support for signed requests (majority of deployments) > 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: 7 Yes: 3 Abstain / Unsure: 3 considerations: - these steps are interdependent - more productive to start from either WRAP or OAuth 1.0a and iterate - hard to compare this approach to a more integrated approach - it all depends on the goals and use cases - OK to have many ways to use a token - need simple bearer token to define the entire flow > 6. Should we go back to working on a single specification? Yes: 8 No: 2 Doesn't matter: 2 Abstain / Unsure: 1 > 7. Do you think the protocol should include a signature-based > authentication scheme? Yes: 10 No / make it optional: 2 Depends on use cases: 1 /psa
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
