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