Subject: [OAUTH-WG] Meeting Notes from the Interim Meeting

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 7 Jun 2010 15:39:51 +0300

OAuth 2.0 Draft 5 Issues List

Intro:
- Purposes/use cases should appear in intro
- Describe role wrt OpenID and auth schemes ??
- Requirements should be removd out of intro

Intro should describe goals and possibilities of OAuth
- Requirements is a limited set, but it should be clarified that they're not the *only* reqs

Terminology:
- We don't say what client secret is
- Describe relationships between terms
- Cryptographic terms ??
- Verification code
- Cliented defined as HTTP, not the case s/Cliented/Client/
- Should use the term "capability" when talking about bearer tokens.

Overview:
- Should relate to Intro (confusing)
- Standardization of tokens should be called out as defined elsewhere
- Call out the face that separation of resource and authz serviers is not in scope
- Intro talks about three flows. We have 6, maybe 7 or 8
(Terminology: Call that bearer tokens are access tokens and cover cryptographic variant)

Examples:
- Scope?
- Best one?

Conformance:
- Useful?

3.2 End-user endpoint

- Can we call it "approval url" instead? - Brian Eaton
- No mandatory to implement language.  That's an interop problem. - Peter St. Andre
- No guidelines or examples of how to verify user identity. - ????
- When using TLS/SSL: make sure it's server authentication, not client certificates. - Eve Maler
- User-uri attribute is very experimental, no clients using anything like this today.  We should have a couple of working clients.
- Explain that end-user endpoint only relevant to some flows.
- Should standardize existing service provider specific parameters for UI, e.g. language, display type, user hint.  (Brian Eaton)

3.3 Token endpoint
- First sentence not true for all flows.  But don't change it at the expense of readability.  - David Recordon
- "Token issuing endpoint" might need a new name.
- MUST use SSL?
- Mandate POST? - Marius Scurtescu
- Security requirements depend on type of authentication used.
- Should authorization server return token type?  Should client use token type?  - Dick Hardt

3.3.1 Client Authentication
- need new text for certificate authentication - Peter St. Andre
- need more flexible language - Justin Smith

3.3.2 Response Format
- Do we need so many formats?
- Are all formats needed on both sides? - Jim Fenton
- Please pick just one.  - Justin Smith
- What if XML becomes uncool?  - Leah Culver
- Data model problem, not all formats support all data types we might need.  - Justin Smith
- Is no-store enough of a cache-control header?  - Chuck Mortimore

3.3.2.1 Access Token Response
- Define scope once, include by reference.  - Peter St. Andre and Eve Maler
- Need "scope" example - Hannes
- Scope is underspecified. - Hannes
- Authorization server MUST honor client request for token secret?  - Justin Smith
- Semantics of "expires_in" are underspecified. - Hannes
- expires_in: duration or absolute time? - Jim Fenton had an opinion

3.3.2.2 Error response
- Data format needs to be in sync across entire spec.  Either allow XML here, or drop it everywhere.  - Justin Smith and others
- Add debugging message field to JSON. - Marius Scurtescu
- Predefined list of error responses?

3.4 Flow Parameters
- More on error handling? - Peter St. Andre

3.5 User-Agent Flow
- If refresh token leaks, you can't recover.  Changing client secret is not enough. - Brian Eaton
- Desktop and mobile applications work.  - David Recordon
- Can we change order of user-agent and web app flow in spec? - Leah Culver
- WRAP web server flow was more secure for rich-client apps, because web sites cannot pretend to be rich clients.  User-Agent flow does not allow this. -  Sarah Faulkner
- Where do we handle custom protocol schemes in redirect URIs? - Blaine Cook and Marius Scurtescu
- Mention that security is based on user-agent same-origin policy - Zachary Zeltsan
- Maybe move installed applications to a separate section - Marius Scurtescu
- Need to give installed app developers a way to specify device name.
- Brian Eaton
- Can  mobile developers use HTTP URL discovery from slide deck instead? - Bill Keenan
- Explain how to authenticate client?

3.5.1 Client Requests Authorization
- What if malicious actor (either user or "man in the browser") tampers with "scope" or "state" parameter? - Eve Maler
- Should we add an extension so that users can self-identify their device? - Bill Smith
- Client state is yucky - Luke Shephard
- Authorization servers MAY restrict the redirection URI to not include a query component. This will break PHP clients.  - Marius Scurtescu

3.5.1.1 End-user grants authorization
- seems odd that client is requesting the token secret - Bill Smith
- what happens if server doesn't want to issue token secret? - Bill Smith and Marius Scurtescu
- should we make example https? - Chuck Mortimore

3.5.1.2 End-user denies authorization
- More error codes needed. - Sarah Faulkner and Marius Scurtescu
- Immedate mode failure needs an error code. - Marius Scurtescu

3.5.2 Client extracts access token
- Can we tell user-agents not to send fragment in HTTP request?  IE does this in certain circumstances. - Brian Eaton

3.6 Web Server Flow

3.6.1 Client Requests Authorization
- redirect_uri validation strategy should be described once in the spec, and then included by reference. - Brian Eaton
- Some of required parameters don't make sense if authentication of user is out of band. - Eve Maler

3.6.1.1 - End-user grants authorization
- What does the verification code provide? - Hannes
- How do people keep verification code from leaking in referer header?
- Sarah Faulkner
- Should we define time-limit for verification code?  5 minutes? - Peter St. Andre
- Specify that verification code should be used only once. - Brian Eaton

3.6.1.2 - End-user denies authorization?

3.6.2 - Client requests access token
- should mention https. - David Recordon

3.7 - Device flow
- mandating polling is terrible  - Leah Culver
- is polling OK if we mandate back-off behavior? - David Recordon
- are there other options besides polling? post backs?  - Leah Culver
- do we even need this?  Is there enough of a use case? - Leah Culver
- is long polling/hanging GET an option? - Brian Eaton
- what about telling user to click a button once they've approved?
- can we get comments from NetFlix or someone who has already done this? - David Recordon
- what about devices with secure storage? - Bill Keenan
- should call out that device manufacture must register with service provider - Brian Eaton
- huh?  Why is that a requirement in this profile?

3.7.1 - Client requests approval
- can we rename "verification uri" to be something else, since it is different than code in web server flow? - Marius Scurtescu

3.7.2 - Client requests access token
- Is "code" REQUIRED or OPTIONAL - Hank
- Can we rename "code" to something else, since it is different? - Marius Scurtescu

3.8 - Username and password flow
- Can we just call this the secure flow? - Blaine
- We can't tell whether the client has really thrown away password. - Hank
- Add to point (B) that client should discard password. - Hank
- should we move client credentials  to basic auth header? - Blaine
- unauthorized_client: has extra apostrophe - Brian
- need to return error URL from this flow , so that users can get their account unblocked if they are on the same IP range as a botnet.
- Brian
- need to fix examples to use "https" instead of "http

3.9 - Client Credentials Flow
- end user is not related to client secret, should eliminate all mention of end user.  - Justin Smith
- should call out absence of end-user in front paragraph. - Leah Culver
- add motivating examples. - Peter St. Andre
- is this the same as username password flow? - Dirk Balfanz

3.9.1 - Client requests access token
- all content-type headers should include charset. - Brian Eaton
- what if developers want to use client secret directly? - David Recordon
- then they should use basic auth - Justin Smith

3.10 - Assertion Flow
- comment on 2.2: section 2.2 still calls this an autonomous flow. - Chuck Mortimore
- if we get client secret right in other flows (e.g. client secret is replaced with assertion), then this flow is no longer necessary. - Justin Smith
- James Manger has been saying the same thing for a while, instead use assertion based HTTP method. - Eran
- we need client id, client secret, and assertion.  This will get confusing.  Let's keep the separate flow. - Chuck
- we need an example. - Leah Culver
- two format parameters.  First should be assertion format. - Marius Scurtescu
- content-type should include charset - Bill Mills
- are we always using json here, or do we support format choice? - Bill Mills

4 - Refresh Token
- should we alway tell clients to use a secret, e.g. "anonymous" or "opensecret"?  Absent secret might be confusing? - Brian Eaton
- can we differentiate between token refresh and changing secret type?
- Dick Hardt
- should we allow down-scoping on this endpoint? - Marius Scurtescu
- scope needs to be figured out through entire flow - Eve Maler
- can we sign with client secret from request, to prevent accidental logging? - Bill Mills
- auth servers can be assumed to be smarter than that. - Allen Tom
- passing client secret across affects lots of flows - Leah Culver
- can we always sign with client secret? - Leah Culver
- we should use POST instead of GET to mitigate risk  - Marius Scurtescu

5 - Accessing a protected resource
- Did anyone read this? - Eran
- No clear error path - Bill Smith
- Can we really call it "Token"? - Leah Culver
- Can we say "bearer tokens" MUST NOT be sent over secure channels? - Jim Fenton
- Can we write a spec that reflects security reality - people do send bearer tokens over HTTP connections - Brian Eaton
- No, we can't.  Security reviewers will block that. - Eran
- People violate specs all the time, we can call them noncompliant and stupid. - Peter St. Andre
- "Token" scheme name is weird.- Dick
- Can we have the discussion to close it out? - Eran
- Why isn't it "OAuth"? - Dick
- What about "OAuth2"? - Dick
- Can we drop name="value" syntax and replace with JSON or something else? - Brian Eaton
- Is changing the header format worth our time? - Eran
- Could treat security considerations better in separate section - Hannes
- Agreed, security here is weak - Peter St. Andre
- Can we call scheme "LessBasic" - Blaine
- Can we say MUST NOT send bearer tokens to unfamiliar sites? - Brian Eaton
- Is "unfamiliar" well-defined? - Jim Fenton
- Can we have a same-origin policy? - Blaine Cook

5.2 - Bearer Token Requests
- Rationalize language here
- Does the token need to explicitly include a bit that says it's a bearer token vs a crypto token.  This is a problem if resource servers support both - Bill Smith
- Text/terms should be a bit clearer on differentation. - Bill Smith
- We should drop realm, it has no meaningful semantics here. - Brian Eaton
- We have to update RFC 2617 to do that.  - Eran
- Let's do it. - Brian Eaton

5.2.1. Query String
- what about protected resources that accept both OAuth1 and OAuth2?
We have a parameter name conflict here.

5.2.2 Post body
- this introduces yet another way to return error responses (401 response vs response body).  Can we make this consistent? - Bill Smith
- this applies throughout the spec. - Eran
- what happens if both query and post body have oauth_token? -
- can we eliminate oauth_token in post body? - Eran
- no, some tokens don't fit in query, and you don't have access to headers. - Dick
- Can we either always use "token" or always use "oauth_token"? - Bill Smith
- We don't need to be consistent. - Eran

5.3  Cryptographic Signatures
- we're probably going to change this dramatically. - Hannes
-

6 - Identifying a protected resource
- should we add error handling here? You'll never return this unless the request was made in error regardless.  - Leah Culver
- should name be "identifying authentication requirements for a resource"? - Eve Maler
- there should be examples and pictures.  - Eve Maler, Eran

6.1 - WWW-Authenticate Response header
- what about resources that return public data if request is unauthenticated?  Facebook does this. - David Recordon
- POST vs GET might have different security policy for example. - David Recordon

6.1.1. - describing the WWW-Authenticate response header
- we need a way to puke back an approval URL. - Bill Smith
- we need to enumerate the types of flows that are supported so that clients can pick the flow to use.  - Bill Smith
- can we scrap this entire section and let Bill figure this out for IMAP?  And then write down what he did instead.  Or move this section to an extension? - Brian Eaton
- ABNF problem?  Is pound notation space delimited? - Jim Fenton
- Maybe think about how oauth discovery should work? - Dirk Balfanz
- is scope a URI or a string? ABNF says URI ,should be string. - Chuck

7 - Security Considerations
- can we reuse the WRAP security considerations? - Brian Eaton
- no.  Needs to be more authoritative. Rewrite it to change the voice. - Eran
- can we reuse the NIST approach in special publication 800-6 of defining specific levels of security along with necessary requirements to meet that level? - Hannes

Appendix A - Differences from OAuth 1.0a
- can someone volunteer for this? - Eran

Authors and Acknowledgements
- do we need three separate classes of contributors? - Eran
- typically have authors and editors, contributors, and acknowledgements. - Hannes

Discussion Notes

What response formats should we use? (Eran Leads)
1) Clients always send form-encoded query or post body
2) Servers can
  - return form-encoded in query uri or fragment
  - form-encoded body
3) Discussion on list about servers returning JSON instead
  - what if JSON is too heavy?
  - what if APIs use XML?

Nobody has suggested using XML only.
People have said: should only support one format, but they don't care much which one.
People have said: should only support JSON People have said: servers implement all three, clients indicate their preference.
   Con: too much complexity, too little value
   Con: this has data model implications for the future, e.g. how will we serialize arrays in XML?

Easy way out: can we all agree on either JSON or form-encoded for responses?
 - no one thinks form-encoded only
 - some support for json only
 - some support for supporting both json and form-encoded

Leah: it is bad to require JSON, because it's not built into python before 2.6.
David: APIs are returning JSON anyway, so claiming that libraries don't need JSON is silly.

Blaine: let's make form-encoded required, but support JSON as an optional response type.

It's weird to have APIs return XML, but authentication services that return JSON.

Dick: when you are working with bearer tokens, you don't need a library at all... except for the form-encoding.  And they are likely to be using JSON for APIs.  So going pure JSON makes things strictly simpler for developers.  This is backed out by WRAP implementation experience.

Eran: form-encoding is like the OAuth signature base string: it looks easy, but developers write their own and get it wrong.

Eran: do people have in their heads use-cases when people want to return more than name/value pairs in responses?  If there are needs for that, we should go with JSON now.

Marius: if someone has trouble parsing form-encoded, they will have trouble with JSON as well.

Marius: we are forcing people to generate form-encoded data, which is harder.

Mariius: there are several profiles where repsonses are returned on query/fragment that still require parsing form-encoded parameters?

David: parsing form-encoded is tricky, people do try to do it themselves and get it wrong.

Marius: but...

Dick: hey, I have the talking stick!

Dick: we ran into problems at microsoft with developers messing up parsing form-encoded.  We talked with other large service providers, and they had the same experience.

...: in order to prevent bugs, we have to keep the data format.

Blaine: this is built into PHP, see urldecode function.

Marius: there are flows that require parsing form-encoded *no matter what*.  We aren't actually going to remove the need for parsing form-encoded by switching to JSON.  For example, redirect URI has "error_code=user_denied".

Dick: there are tools for parsing URLs parameters.  This is what web servers do automatically.

Marius: what about rich clients?  They don't have the web server to do it for them.

Leah: some of this is language dependent.

Dick: no it isn't.

Leah: yes it is.  It's built into python.  There is a method that builds dictionaries from name/value pairs.

David: python 2.6 has been out since October, 2008.

Brian: signing is going to end up using JSON.

Chuck: adding three repsonse formats at service provider is pretty cheap, we should just do it.

... more discussion, Brian left the room...
... wow, I am all the way down the hall and I can hear people yelling ...
... chairs close discussion.

New topic: how do we unify error responses?
Eran: we need different response formats for API calls vs Authorization server calls?
... Brian is a flaky note taker...

Blaine and Peter - what should we talk about now?

What about custom protocol handlers?
Eran: we can't recommend existing practice (make up random protocol
handler) because it violates IETF rules.  But we could recommend good practice for the future.  Something about using app: URIs.

Leah: everybody knows how to do this.

Blaine: lots of twitter developers don't know how to do this.

Brian: we've run sessions at IIW every six months for the past two years on how to do this.  People still think it's impossible.

Blaine: Eran's suggestion seems reasonable.