Subject: [OAUTH-WG] OAuth meeting notes on -05 (with updates)

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 14 Jun 2010 23:35:02 -0700

During the OAuth WG interim meeting, the group spent a considerable amount of time going over draft -05 and listing issues with the text and protocol. Since the draft is now significantly different, I want to go over this and identify the issues resolved and those still open (before it is too late).

These comments are based on Brian Eaton's detailed notes (thanks!) with my edits. I removed comments that were not actionable. I kept the names next to comments where additional clarifications are needed. If the notes are wrong, blame me for messing with the Brian's copy.

Action items are marked with ***.

Overall, I think by -09 we will be done with most of the comments (ready for another batch).

EHL

---

> Introduction:
>
> - Add purposes / use cases
> - Describe how it relates to other authentication schemes (OpenID, HTTP Auth)
> - Move requirements out of the introduction
> - Describe goals and possibilities
> - Clarify that the listed requirements are not the only ones

I'm generally happy with the current outline for the introduction. Those looking to address these points should submit text proposals.

> Terminology:
> - Define client secret

Client secret isn't a term but a detail of the client authentication process, especially with the way it is defined now.

> - Describe relationship between terms

The section has been restructured to add two levels of terms to show relationships.

> - Add verification code

The verification code was renamed to authorization code and added.

> - Remove terminology references to HTTP terms

Removed reliance on HTTP terminology.

> - Add cryptographic terms
> - User the term 'capability' when talking about bearer tokens

Since the signature and cryptography was removed, these comments are no longer relevant for this draft.

> Overview:
>
> - Does not related to the introduction (confusing)

The overview section was written from scratch so hopefully it is less confusing.

> - Standardization of tokens should be called out as defined elsewhere
> - Explain that the separation between the authorization server and resource server is out of scope

Both will be clarified in -09.

> - Flow grouping is confusing

Since the flows have been incorporated into the introduction, and the grouping removed, the confusion should be resolved.

> 3.2 End-user endpoint:
>
> - Rename 'end-user endpoint' to 'approval url'

Renamed to 'end-user authorization endpoint'.

> - No mandatory to implement language - interop problem (Peter St. Andre)

*** Please clarify what should be required.

> - Does not mention user identity (how to verify)

User identity is out of scope. Should be addressed by the proposed OpenID Connect work.

> - When using TLS, make sure it's server authentication, not client certificates (Eve Maler)

*** Please propose language.

> - 'user-uri' attribute is too experimental to be included

Moved to discovery draft.

> - Explain that the end-user endpoint is only relevant to some flows

I think -08 makes this clear.

> - Should standardize existing service provider specific parameters for UI, e.g. language, display type, user hint

Published in a separate UX draft.

> 3.3 Token endpoint:
>
> - First sentence ("After obtaining authorization from the resource owner") is not true for all flows

I think the same issue exists in -08 but I'm not sure how to address it. Is it really a problem?

> - Maybe change name to 'Token issuing endpoint'

I think token endpoint is nice and short.

> - MUST use SSL?

Changed to "Servers MUST support TLS 1.2" and may support other stuff (equally strong) as well.

> - Mandate POST?

Yes. Otherwise secrets leak into log files.

> 3.3.1 Client Authentication:
>
> - Need new text for certificate authentication
> - Need more flexible language

The latest draft fixes this by moving the client authentication out of the endpoints and into its own section. In addition, the client identifier and secret are given a name (basic client credentials) to make it easier to specify other ways to authenticate the client.

> 3.3.2 Response Format:
>
> - Do we need so many formats?
> - Are all formats needed on both sides?

Solved by using just JSON for token endpoint responses.

> - Is no-store enough of a cache-control header? (Chuck Mortimore)

*** No idea. Is it?

> 3.3.2.1 Access Token Response:
>
> - Define scope once, include by reference

Don't even need to reference anymore. Defined in a single place.

> - Need “scope” example (Hannes)

*** It is hard to provide scope examples. Are there any scopes common in more than one OAuth 1.0 implementation?

> - Scope is underspecified

It is as specified as we have consensus for (even this was painful).

> - Authorization server MUST honor client request for token secret?

Since this is moved to an extension, the answer is no.

> - Semantics of “expires_in” are underspecified

Added example in -09.

> 3.3.2.2 Error response:
>
> - Data format needs to be in sync across entire spec

Now uses JSON like a successful response.

> - Add debugging message field to JSON

Debugging is out of scope, but feel free to write a proposal.

> - Predefined list of error responses?

New section added in -07. Still needs to add text to describe each error message, as well as make the list complete.

> 3.4 Flow Parameters:
>
> - More on error handling? (Peter St. Andre)

*** Not sure what this is about.

> 3.5 User-Agent Flow:
>
> - If refresh token leaks, you can’t recover.  Changing client secret is not enough.

No longer issuing refresh token in user-agent flow.

> - Can we change order of user-agent and web app flow in spec?

Done.

> - 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)

*** Please start a new thread to discuss.

> - Where do we handle custom protocol schemes in redirect URIs?

*** Currently mentioned in native application section. Need guidance from IESG on how to handle this so it will not become a blocking issue.

> - Move installed applications to a separate section

Done.

> - Need to give installed app developers a way to specify device name (Brian Eaton)

*** Please propose text.

> - Can mobile developers use HTTP URL discovery from slide deck instead? (Bill Keenan)

*** Need clarification.

> - Explain how to authenticate the client.
 
I think the new text is pretty clear, using a reference to the client authentication section.

> 3.5.1 Client Requests Authorization:
>
> - What if malicious actor (either a user or “man in the browser”) tampers with “scope” or “state” parameter? (Eve Maler)

Since the end-user gets to authorize the request, scope tempering shouldn't be a problem. As for state, I'm not sure.

> - Should we add an extension so that users can self-identify their device? (Bill Smith)

*** Please propose text or start a discussion.

> - Authorization servers MAY restrict the redirection URI to not include a
> query component. This will break PHP clients

This is part of the underspecified matching rules. I'll drop it for now.

> 3.5.1.1 End-user grants authorization:
>
> - seems odd that client is requesting the token secret.
> - what happens if server doesn’t want to issue token secret?

Removed. Still an open question for the signature spec.

> - should we make example https?

I don't think this is necessary since the fragment is not transmitted.

> 3.5.1.2 End-user denies authorization:
>
> - More error codes needed (Sarah Faulkner and Marius Scurtescu)

*** Please provide text.

> - Immediate mode failure needs an error code

Removed. Noted for when the parameter appears on another draft.

> 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.

HTTP tells that. It was made more explicit in the new HTTPbis work. Beyond that, not sure what we can do.

> 3.6.1 Client Requests Authorization:
>
> - redirect_uri validation strategy should be described once in the spec, and then included by reference.

Done.

> - Some of the required parameters don’t make sense if authentication of user is out of band. (Eve Maler)

The only required parameter there were 'client_id', 'type', and 'redirect_uri'. Which one are you referring to?

> 3.6.1.1 - End-user grants authorization:
>
> - What does the verification code provide?

I think the new text explains this (part of the abstraction layer provided by the access grant). Let me know if it still needs to be clarified.

> - How do people keep verification code from leaking in referrer header? (Sarah Faulkner)

*** Is this an issue? Can you start a thread to discuss?

> - Should we define time-limit for verification code?  5 minutes? (Peter St. Andre)

*** Open issue.

> - Specify that verification code should be used only once

Made even clearer in -09.

> 3.6.2 - Client requests access token:
>
> - should mention https

Done.

[Device flow feedback removed]

> 3.8 - Username and password flow:
>
> - 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 Eaton)

*** Please suggest text.

> 3.10 - Assertion Flow:
> - we need an example

Done.

> - Two format parameters

Fixed.

> 4 - Refresh Token:
>
> - should we alway tell clients to use a secret, e.g. “anonymous” or “opensecret”?  Absent secret might be confusing? (Brian Eaton)

*** Please clarify.

> - Should we allow down-scoping on this endpoint?

-08 adds support for down-scoping.

> - Scope needs to be figured out through entire flow (Eve Maler)

*** -08 tries to clean up scope handling. Please review.

> 5 - Accessing a protected resource:
>
> - No clear error path

Noted. To be addressed in -09.

> - Should the authentication scheme name be called 'Token'?

I think so. Those who disagree are welcome to start a discussion.

> - Can we say “bearer tokens” MUST NOT be sent over secure channels? (Jim Fenton)

I would like that but consensus was that SHOULD NOT is the strongest we can specify.

> - Can we write a spec that reflects security reality - people do send bearer tokens over HTTP connections

We did :-(

> - Can we say MUST NOT send bearer tokens to unfamiliar sites?

Done in -09.

> - Is “unfamiliar” well-defined?

I think it is in the context of the spec - not hardcoded into the client.

> - Can we have a same-origin policy?

This needs to be addressed in the discovery spec. James' propose 'sites' parameter is one approach.

> 5.2 - Bearer Token Requests:
>
> - We should drop realm, it has no meaningful semantics here

*** I will float this past the HTTP folks to gage their reaction.

> 6.1 - WWW-Authenticate Response header:
>
> - what about resources that return public data if request is unauthenticated? POST vs GET might have different security policy.

*** Need to look into this.

> 6.1.1. - describing the WWW-Authenticate response header
>
> - Discovery needed for various elements

Yes. That's for the discovery draft.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 15 Jun 2010 08:56:46 +0200

> resource server is out of scope

Why is this out of scope? I consider this a major improvement over  
Oauth 1.0.

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 15 Jun 2010 00:16:56 -0700

How they communicate is out of scope.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Monday, June 14, 2010 11:57 PM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] OAuth meeting notes on -05 (with updates)

Why is this out of scope? I consider this a major improvement over Oauth 1.0.

regards,
Torsten.

Am 15.06.2010 um 08:35 schrieb Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>:
- Explain that the separation between the authorization server and resource server is out of scope

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 15 Jun 2010 09:31:08 +0200

ok, understood.

---

From: <[email-masked]>
Date: Tue, 15 Jun 2010 15:10:03 +0200

During the meeting we had a (short) discussion about the expires_in parameter.
I propose to change it to a notonorafter parameter with a GMT/UTC date as value.
If the time slew between server is bigger or nearly equal to the life time of the expires_in value than the token receiver has no chance to detect that the token is dead on arrival.
Or we could keep the name expires_in but change the value from a relative unit (seconds) to a absolute one (Date)

-Axel

expires_in
         OPTIONAL.  The duration in seconds of the access token lifetime.

notonorafter
         OPTIONAL.  Specifies the time instant at which the assertion has expired in universal time coordinates.

Example
	notonorafter="2007-08-21T08:18:50.605Z"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, June 15, 2010 8:35 AM
To: OAuth WG ([email-masked])
Subject: [OAUTH-WG] OAuth meeting notes on -05 (with updates)

EHL

---

*** No idea. Is it?

> - Need "scope" example (Hannes)

> - Semantics of "expires_in" are underspecified

Added example in -09.

> 3.5 User-Agent Flow:
>
> - If refresh token leaks, you can't recover.  Changing client secret is not enough.

Done.

Done.

*** Please propose text.

*** Need clarification.

> - What if malicious actor (either a user or "man in the browser") tampers with "scope" or "state" parameter? (Eve Maler)

> - what happens if server doesn't want to issue token secret?

*** Please provide text.

Done.

> - Some of the required parameters don't make sense if authentication of user is out of band. (Eve Maler)

*** Open issue.

Done.

*** Please suggest text.

Done.

Fixed.

> 4 - Refresh Token:
>
> - should we alway tell clients to use a secret, e.g. "anonymous" or "opensecret"?  Absent secret might be confusing? (Brian Eaton)

*** Please clarify.

> - Can we say "bearer tokens" MUST NOT be sent over secure channels? (Jim Fenton)

We did :-(

Done in -09.

> - Is "unfamiliar" well-defined?

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: David Recordon <[email-masked]>
Date: Tue, 15 Jun 2010 08:50:59 -0700

Hey Axel,
We had previously decided (I can try to dig up the link) that relative
times will be easier for client developers. It means no timezone
handling but being able to store the expiration as time() +
expires_in. No, it's not going to be perfect to the second but the AS
could always send an expires_in that is 5? seconds shorter than
reality.

--David

---

From: <[email-masked]>
Date: Tue, 15 Jun 2010 18:28:09 +0200

That killer argument again. I allways tend to overestimate the skills of the developer.
Thanks. 

-Axel

-----Original Message-----
From: David Recordon [mailto:[email-masked]] 
Sent: Tuesday, June 15, 2010 5:51 PM
To: Nennker, Axel
Cc: [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] expires_in RE: OAuth meeting notes on -05 (with updates)

Hey Axel,

--David

---

From: "William Mills" <[email-masked]>
Date: Tue, 15 Jun 2010 09:48:24 -0700

Recordon had a fantastic idea at the interim meeting, using G Wave for comments on the draft, which would have been far superior to the whiteboard.  Perhaps when your ready for another major round of comments the text version can get posted to a wave and folks can annotate.

-bill 

> Sent: Monday, June 14, 2010 11:35 PM
> During the OAuth WG interim meeting, the group spent a 
> considerable amount of time going over draft -05 and listing 
> issues with the text and protocol. Since the draft is now 
> significantly different, I want to go over this and identify 
> the issues resolved and those still open (before it is too late).
> 
> These comments are based on Brian Eaton's detailed notes 
> (thanks!) with my edits. I removed comments that were not 
> actionable. I kept the names next to comments where 
> additional clarifications are needed. If the notes are wrong, 
> blame me for messing with the Brian's copy.
> 
> I'm generally happy with the current outline for the 
> introduction. Those looking to address these points should 
> submit text proposals.
> 
> > Terminology:
> >
> > - Define client secret
> 
> Client secret isn't a term but a detail of the client 
> authentication process, especially with the way it is defined now.
> 
> Since the signature and cryptography was removed, these 
> comments are no longer relevant for this draft.
> 
> > Overview:
> >
> Since the flows have been incorporated into the introduction, 
> and the grouping removed, the confusion should be resolved.
> 
> > 3.2 End-user endpoint:
> >
> > - Should standardize existing service provider specific 
> parameters for 
> > UI, e.g. language, display type, user hint
> 
> The latest draft fixes this by moving the client 
> authentication out of the endpoints and into its own section. 
> In addition, the client identifier and secret are given a 
> name (basic client credentials) to make it easier to specify 
> other ways to authenticate the client.
> 
> > 3.3.2 Response Format:
> >
> *** It is hard to provide scope examples. Are there any 
> scopes common in more than one OAuth 1.0 implementation?
> 
> New section added in -07. Still needs to add text to describe 
> each error message, as well as make the list complete.
> 
> > 3.4 Flow Parameters:
> >
> > - 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)
> 
> *** Currently mentioned in native application section. Need 
> guidance from IESG on how to handle this so it will not 
> become a blocking issue.
> 
> > - Need to give installed app developers a way to specify 
> device name 
> > (Brian Eaton)
> 
> *** Please propose text.
> 
> > - What if malicious actor (either a user or "man in the browser") 
> > tampers with "scope" or "state" parameter? (Eve Maler)
> 
> Since the end-user gets to authorize the request, scope 
> tempering shouldn't be a problem. As for state, I'm not sure.
> 
> > - Authorization servers MAY restrict the redirection URI to not 
> > include a query component. This will break PHP clients
> 
> > - Can we tell user-agents not to send fragment in HTTP request?  IE 
> > does this in certain circumstances.
> 
> HTTP tells that. It was made more explicit in the new HTTPbis 
> work. Beyond that, not sure what we can do.
> 
> > - redirect_uri validation strategy should be described once 
> in the spec, and then included by reference.
> 
> Done.
> 
> > - Some of the required parameters don't make sense if 
> authentication 
> > of user is out of band. (Eve Maler)
> 
> The only required parameter there were 'client_id', 'type', 
> and 'redirect_uri'. Which one are you referring to?
> 
> I think the new text explains this (part of the abstraction 
> layer provided by the access grant). Let me know if it still 
> needs to be clarified.
> 
> > - 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 
> > Eaton)
> 
> *** Please suggest text.
> 
> > 3.10 - Assertion Flow:
> >
> > - we need an example
> 
> Done.
> 
> > - Two format parameters
> 
> Fixed.
> 
> > 4 - Refresh Token:
> >
> > - should we alway tell clients to use a secret, e.g. "anonymous" or 
> > "opensecret"?  Absent secret might be confusing? (Brian Eaton)
> 
> *** Please clarify.
> 
> > - Can we write a spec that reflects security reality - 
> people do send 
> > bearer tokens over HTTP connections
> 
> We did :-(
> 
> This needs to be addressed in the discovery spec. James' 
> propose 'sites' parameter is one approach.
> 
> > - what about resources that return public data if request 
> is unauthenticated? POST vs GET might have different security policy.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 15 Jun 2010 09:40:46 -0700

I prefer to keep this as seconds. In most cases, this will be good enough and will not require any clock sync. Servers should not issue tokens with durations that are too short and likely to expire during processing. If clock sync is requires, the client can use the server's Date response header field to figure out the absolute expiration time.

EHL

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 15, 2010 6:10 AM
> To: Eran Hammer-Lahav; [email-masked]
> Subject: expires_in RE: [OAUTH-WG] OAuth meeting notes on -05 (with
> updates)
> 
> 
> If the time slew between server is bigger or nearly equal to the life time of
> the expires_in value than the token receiver has no chance to detect that
> the token is dead on arrival.
> During the OAuth WG interim meeting, the group spent a considerable
> amount of time going over draft -05 and listing issues with the text and
> protocol. Since the draft is now significantly different, I want to go over this
> and identify the issues resolved and those still open (before it is too late).
> 
> These comments are based on Brian Eaton's detailed notes (thanks!) with my
> edits. I removed comments that were not actionable. I kept the names next
> to comments where additional clarifications are needed. If the notes are
> wrong, blame me for messing with the Brian's copy.
> 
> I'm generally happy with the current outline for the introduction. Those
> looking to address these points should submit text proposals.
> 
> > Terminology:
> >
> > - Define client secret
> 
> Client secret isn't a term but a detail of the client authentication process,
> especially with the way it is defined now.
> 
> Since the flows have been incorporated into the introduction, and the
> grouping removed, the confusion should be resolved.
> 
> > 3.2 End-user endpoint:
> >
> > - Should standardize existing service provider specific parameters for
> The latest draft fixes this by moving the client authentication out of the
> endpoints and into its own section. In addition, the client identifier and
> secret are given a name (basic client credentials) to make it easier to specify
> New section added in -07. Still needs to add text to describe each error
> message, as well as make the list complete.
> 
> > 3.4 Flow Parameters:
> >
> > - 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
> *** Currently mentioned in native application section. Need guidance from
> IESG on how to handle this so it will not become a blocking issue.
> 
> Since the end-user gets to authorize the request, scope tempering shouldn't
> be a problem. As for state, I'm not sure.
> 
> I think the new text explains this (part of the abstraction layer provided by
> the access grant). Let me know if it still needs to be clarified.
> 
> > - 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
> > Eaton)
> 
> *** Please suggest text.
> 
> > 3.10 - Assertion Flow:
> >
> > - we need an example
> 
> Done.
> 
> > - Two format parameters
> 
> Fixed.
> 
> > 4 - Refresh Token:
> >
> > - what about resources that return public data if request is
> unauthenticated? POST vs GET might have different security policy.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 15 Jun 2010 09:56:30 -0700

No thanks.

I much prefer posts on this list. I would be best if people didn't sent one email with a long list of issues, but instead posted each issue separately to help manage the discussion.

EHL

> From: William Mills [mailto:[email-masked]]
> Sent: Tuesday, June 15, 2010 9:48 AM
> Subject: RE: [OAUTH-WG] OAuth meeting notes on -05 (with updates)
> 
> Recordon had a fantastic idea at the interim meeting, using G Wave for
> comments on the draft, which would have been far superior to the
> whiteboard.  Perhaps when your ready for another major round of
> comments the text version can get posted to a wave and folks can annotate.
> 
> -bill
> 
> > amount of time going over draft -05 and listing issues with the text
> > and protocol. Since the draft is now significantly different, I want
> > to go over this and identify the issues resolved and those still open
> > (before it is too late).
> >
> > (thanks!) with my edits. I removed comments that were not actionable.
> > I kept the names next to comments where additional clarifications are
> > needed. If the notes are wrong, blame me for messing with the Brian's
> > copy.
> >
> > I'm generally happy with the current outline for the introduction.
> > Those looking to address these points should submit text proposals.
> >
> > > Terminology:
> > >
> > > - Define client secret
> >
> > Client secret isn't a term but a detail of the client authentication
> > process, especially with the way it is defined now.
> >
> > The latest draft fixes this by moving the client authentication out of
> > the endpoints and into its own section.
> > In addition, the client identifier and secret are given a name (basic
> > client credentials) to make it easier to specify other ways to
> > authenticate the client.
> >
> > > 3.3.2 Response Format:
> > >
> > *** It is hard to provide scope examples. Are there any scopes common
> > in more than one OAuth 1.0 implementation?
> >
> > New section added in -07. Still needs to add text to describe each
> > error message, as well as make the list complete.
> >
> > > 3.4 Flow Parameters:
> > >
> > *** Currently mentioned in native application section. Need guidance
> > from IESG on how to handle this so it will not become a blocking
> > issue.
> >
> > Since the end-user gets to authorize the request, scope tempering
> > shouldn't be a problem. As for state, I'm not sure.
> >
> > The only required parameter there were 'client_id', 'type', and
> > 'redirect_uri'. Which one are you referring to?
> >
> > I think the new text explains this (part of the abstraction layer
> > provided by the access grant). Let me know if it still needs to be
> > clarified.
> >

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 22 Jun 2010 13:02:51 +1000

Eran,

There have been a few mentions recently of an OAuth discovery draft. Is there any such draft yet, or is this just a part that we know needs to be done?

A wiki page on "Future OpenID Technical Requirements" <http://wiki.openid.net/Future-OpenID-Technical-Requirements> says:

> 6) IdP Discovery
>
>    * Much of this will be covered by OAuth2 Discovery,
>      however OIC may need to define OpenID specific features.
>…
> 17) Simpler discovery
>
>    * See Eran's OAuth Discovery proposal

There was an OAuth 1.0 Discovery draft over 2 years ago, but that is tagged: "expired", "marked as obsolete by its author", "discouraged from implementing", "no update is expected", "replaced by the OAuth 2.0 effort".

I know I should write a discovery draft myself.

-- 
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 21 Jun 2010 21:50:00 -0700

Yes, it's on my desk and not yet ready, but I am working on one. It includes your sites proposal among other things. I am trying to get the core spec stable this week and focus on that next.

EHL

> From: Manger, James H [mailto:[email-masked]]
> Sent: Monday, June 21, 2010 8:03 PM
> To: Eran Hammer-Lahav; OAuth WG ([email-masked])
> Subject: OAuth discovery draft?
> 
> Eran,
> 
> There have been a few mentions recently of an OAuth discovery draft. Is
> there any such draft yet, or is this just a part that we know needs to be
> done?
> 
> A wiki page on "Future OpenID Technical Requirements"
> <http://wiki.openid.net/Future-OpenID-Technical-Requirements> says:
> 
> > 6) IdP Discovery
> >
> There was an OAuth 1.0 Discovery draft over 2 years ago, but that is tagged:
> "expired", "marked as obsolete by its author", "discouraged from
> implementing", "no update is expected", "replaced by the OAuth 2.0 effort".
>

---

From: Yaron Goland <[email-masked]>
Date: Wed, 23 Jun 2010 18:00:21 +0000

I've been noodling [1] a lot about full delegation in OAuth [2] and one of the issues that came out of that was the need for discovering both the location and realm of an endpoint's token server. But at least for my use cases (which consist of walking up to a service and making an options request and getting back a www-authenticate header) all I need back is a realm and a token server URL. In other words just having one argument added to our www-authenticate header would be enough to solve the case where someone wants to walk up to a service and find out where its token server is. Does that really need its own spec? Or can we just add an argument to www-authenticate in the current spec?
	Thanks,
		Yaron

[1] See http://www.goland.org/oauthgenericdelegation/ for an overview of my thinking on full delegation in OAuth. At the very end are links to a bunch of other much more in-depth articles on particular subjects touched on in the main article.

[2] I define 'full delegation' as "User X of Service Y grants permission Z to User A of Service B". Currently OAuth requires X == A. In the future I hope to see extensions to OAuth that enable what I'm terming 'full delegation'. But personally I'm really happy that OAuth has the X==A restriction. It simplifies a whole host of issues and satisfies a really important use case.

> Sent: Monday, June 21, 2010 9:50 PM
> To: Manger, James H; OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] OAuth discovery draft?
> 
> Yes, it's on my desk and not yet ready, but I am working on one. It includes
> your sites proposal among other things. I am trying to get the core spec
> stable this week and focus on that next.
> 
> EHL
> 
> > There have been a few mentions recently of an OAuth discovery draft.
> > Is there any such draft yet, or is this just a part that we know needs
> > to be done?
> >

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 23 Jun 2010 11:03:48 -0700

I think the core work is pretty stable now, unlike the discovery bits which (while simple) are not enjoying the same level of consensus. I think it is much more practical to propose them as a separate document and perhaps consider merging them later on when they reach an equal level of stability. But overall, I'm not too worries about multiple documents.

EHL

On 6/23/10 11:00 AM, "Yaron Goland" <[email-masked]> wrote:

> > >...

---

From: Yaron Goland <[email-masked]>
Date: Wed, 23 Jun 2010 18:20:27 +0000

No objections on my part. I would rather have a smaller core spec with features that everyone agrees on.

BTW, a thought for the discovery draft - RFC 2616/2617 only defines www-authenticate's semantics in the context of a 401. It's unclear from the draft what it would mean to return a www-authenticate header on a 200 response. The reason I care about this is that I think it makes sense that if someone wants to talk to an endpoint they know supports OAuth and need to know where their token issuer location is they would want to fire off an OPTIONS request to the resource and find out from the response where the issuer is and what realm is being used. It seems to me that the simplest way to solve this problem is to just return www-authenticate on a 200 response to an OPTIONS request.

                Thoughts?

                                Thanks,

                                                Yaron

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Wednesday, June 23, 2010 11:04 AM
To: Yaron Goland; James Manger; OAuth WG
Subject: Re: OAuth discovery draft?

EHL

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 23 Jun 2010 14:39:59 -0400

Hi Yaron,

I think delegation is a great idea/feature that should be added or OAuth (as I suggested in the kerberos-oauth draft). In the Kerberos world, it has been a very important feature (a life saver).

In your example, when Yochi wants to terminate the delegation she gave to Leon, how does Yochi do this?

Also, would it be possible for Yochi to delegate to another system (not a human user) to do things for her. For example, give delegation to a 3rd party service/system to (a) regularly fetch Yochi's Saturday/Sunday schedule from Yahoo Calendar, and then (b) publish it to FaceBook say.

/thomas/

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yaron Goland
> Sent: Wednesday, June 23, 2010 2:00 PM
> To: Eran Hammer-Lahav; Manger, James H; OAuth WG ([email-masked])
> I've been noodling [1] a lot about full delegation in OAuth [2] and one
> of the issues that came out of that was the need for discovering both
> the location and realm of an endpoint's token server. But at least for
> my use cases (which consist of walking up to a service and making an
> options request and getting back a www-authenticate header) all I need
> back is a realm and a token server URL. In other words just having one
> argument added to our www-authenticate header would be enough to solve
> the case where someone wants to walk up to a service and find out where
> its token server is. Does that really need its own spec? Or can we just
> add an argument to www-authenticate in the current spec?
> 	Thanks,
> 		Yaron
> 
> [1] See http://www.goland.org/oauthgenericdelegation/ for an overview
> of my thinking on full delegation in OAuth. At the very end are links
> to a bunch of other much more in-depth articles on particular subjects
> touched on in the main article.
> 
> [2] I define 'full delegation' as "User X of Service Y grants
> permission Z to User A of Service B". Currently OAuth requires X == A.
> In the future I hope to see extensions to OAuth that enable what I'm
> terming 'full delegation'. But personally I'm really happy that OAuth
> has the X==A restriction. It simplifies a whole host of issues and
> satisfies a really important use case.
> 
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Eran Hammer-Lahav
> > Yes, it's on my desk and not yet ready, but I am working on one. It
> > includes your sites proposal among other things. I am trying to get
> > the core spec stable this week and focus on that next.
> >
> > EHL
> >
> > > Is there any such draft yet, or is this just a part that we know
> > > needs to be done?
> > >

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Jun 2010 09:45:01 -0700

I have completed all my action items. I have not seen any responses to this list (in two weeks) and will be closing these issues on my end (editor's queue). If you still want to discuss this, please bring it up again.

EHL

> > - What if malicious actor (either a user or “man in the browser”)
> > tampers with “scope” or “state” parameter? (Eve Maler)
> 
> > - should we alway tell clients to use a secret, e.g. “anonymous” or
> > “opensecret”?  Absent secret might be confusing? (Brian Eaton)
> 
> *** Please clarify.
>

---

From: Yaron Goland <[email-masked]>
Date: Fri, 25 Jun 2010 18:33:55 +0000

Revocation - My assumption is that Yochi would tell Yahoo Calendar to pull Leon's permission. This would happen out of band. When Live Calendar (Leon's service provider) tries to use its refresh token to get an access token from Yahoo's token endpoint the request will fail because the permission is gone. I have thought about having a 'negative' permission flow (e.g. a notification that a permission is no longer provided) but there are social issues with this that make me wonder if it's viable. Think of unfriending people in Facebook. You don't get a notification that someone has unfriended you for just that reason.

Re-Delegation - This is one of those features that makes sense in theory but I'm not convinced normal humans (and that includes developers) can grok. I think we should start with 1:1 permissions for now. In other words for the scenario you gave below Yochi would have to directly grant permission to the 3rd party service to both the Yahoo Calendar and Facebook accounts.

But that's really just my opinion,

		Thanks,

			Yaron

> From: Thomas Hardjono [mailto:[email-masked]]
> Sent: Wednesday, June 23, 2010 11:40 AM
> To: Yaron Goland; OAuth WG ([email-masked])
> Subject: RE: OAuth discovery draft?
> 
> 
> Hi Yaron,
> 
> I think delegation is a great idea/feature that should be added or OAuth (as I
> suggested in the kerberos-oauth draft). In the Kerberos world, it has been a
> very important feature (a life saver).
> 
> Also, would it be possible for Yochi to delegate to another system (not a
> human user) to do things for her. For example, give delegation to a 3rd party
> service/system to (a) regularly fetch Yochi's Saturday/Sunday schedule from
> Yahoo Calendar, and then (b) publish it to FaceBook say.
> 
> /thomas/
> 
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 26 Jun 2010 08:09:01 +0200

I think it should be possible to discover a resource's OAuth server  
and its capabilities using a direct Discovery request. I don't think a  
WWW-Authenticate Header is the right representation for this kind of  
data. What about a JSON or XML document returned in response to an  
OPTIONS request (as you suggested) or a GET request with a certain  
content type in its ACCEPT Header?

regards,
Torsten.

Am 23.06.2010 um 20:20 schrieb Yaron Goland <[email-masked]>:

> BTW, a thought for the discovery draft – RFC 2616/2617 only defines  
> www-authenticate’s semantics in the context of a 401. It’s  
> unclear from the draft what it would mean to return a www-authentica 
> te header on a 200 response. The reason I care about this is that I  
> think it makes sense that if someone wants to talk to an endpoint th 
> ey know supports OAuth and need to know where their token issuer loc 
> ation is they would want to fire off an OPTIONS request to the resou 
> rce and find out from the response where the issuer is and what real 
> m is being used. It seems to me that the simplest way to solve this  
> problem is to just return www-authenticate on a 200 response to an O 
> PTIONS request.
>
>
>
>                 Thoughts?
>
>
>
>                                 Thanks,
>
>
>
>                                                 Yaron
>
>
>
> I think the core work is pretty stable now, unlike the discovery  
> bits which (while simple) are not enjoying the same level of  
> consensus. I think it is much more practical to propose them as a  
> separate document and perhaps consider merging them later on when  
> they reach an equal level of stability. But overall, I’m not too wor 
> ries about multiple documents.
>
> EHL
>
>
> I've been noodling [1] a lot about full delegation in OAuth [2] and  
> one of the issues that came out of that was the need for discovering  
> both the location and realm of an endpoint's token server. But at  
> least for my use cases (which consist of walking up to a service and  
> making an options request and getting back a www-authenticate  
> header) all I need back is a realm and a token server URL. In other  
> words just having one argument added to our www-authenticate header  
> would be enough to solve the case where someone wants to walk up to  
> a service and find out where its token server is. Does that really  
> need its own spec? Or can we just add an argument to www- 
> authenticate in the current spec?
>         Thanks,
>                 Yaron
>
> [1] See http://www.goland.org/oauthgenericdelegation/ for an  
> overview of my thinking on full delegation in OAuth. At the very end  
> are links to a bunch of other much more in-depth articles on  
> particular subjects touched on in the main article.
>
> permission Z to User A of Service B". Currently OAuth requires X ==  
> A. In the future I hope to see extensions to OAuth that enable what  
> I'm terming 'full delegation'. But personally I'm really happy that  
> OAuth has the X==A restriction. It simplifies a whole host of issues  
> and satisfies a really important use case.
>
> needs

---

From: Yaron Goland <[email-masked]>
Date: Mon, 28 Jun 2010 22:10:21 +0000

I believe that GET should be used to return the resource’s state and its OAuth token endpoint is just a tiny part of that state. When we want to return part of the state we typically use either explicit headers (a la byte ranges) or a query parameter. Content-types should, I think, just control the syntax of what is returned, not the subset of data it contains. So I have to admit that I really don’t like using GET for this sort of scenario.

OPTIONS is actually the officially blessed way to walk up to a resource, knock on the front door and ask ‘what are you and what can you do?’ So it seems to me we should start with OPTIONS. But this does bring up a problem – nobody ever really defined a response body for OPTIONS. RFC 2616 explicitly defined the legality of such a body but no standard was defined for what the body should look like. This is an issue because if someone does define a body for OPTIONS then they really need to do so in a way that other standards can build on top of.

So we have a choice when it comes to using OPTIONS. We can return data in the header in which case all we have to do is just define the header, submit the RFC and call it day. Or we can use the body but in that case we probably need to write one spec to define a generic way to return data in OPTIONS response bodies (e.g. how do different OPTIONS responses live together?) and get that standardized. Then we can write a second RFC to define how our specific data would be carried in OPTIONS.

                Thoughts?

                                Yaron

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Friday, June 25, 2010 11:09 PM
To: Yaron Goland
Cc: Eran Hammer-Lahav; James Manger; OAuth WG
Subject: Re: [OAUTH-WG] OAuth discovery draft?

I think it should be possible to discover a resource's OAuth server and its capabilities using a direct Discovery request. I don't think a WWW-Authenticate Header is the right representation for this kind of data. What about a JSON or XML document returned in response to an OPTIONS request (as you suggested) or a GET request with a certain content type in its ACCEPT Header?

regards,
Torsten.

Am 23.06.2010 um 20:20 schrieb Yaron Goland <[email-masked]<mailto:[email-masked]>>:
No objections on my part. I would rather have a smaller core spec with features that everyone agrees on.

BTW, a thought for the discovery draft – RFC 2616/2617 only defines www-authenticate’s semantics in the context of a 401. It’s unclear from the draft what it would mean to return a www-authenticate header on a 200 response. The reason I care about this is that I think it makes sense that if someone wants to talk to an endpoint they know supports OAuth and need to know where their token issuer location is they would want to fire off an OPTIONS request to the resource and find out from the response where the issuer is and what realm is being used. It seems to me that the simplest way to solve this problem is to just return www-authenticate on a 200 response to an OPTIONS request.

                Thoughts?

                                Thanks,

                                                Yaron

I think the core work is pretty stable now, unlike the discovery bits which (while simple) are not enjoying the same level of consensus. I think it is much more practical to propose them as a separate document and perhaps consider merging them later on when they reach an equal level of stability. But overall, I’m not too worries about multiple documents.

EHL

On 6/23/10 11:00 AM, "Yaron Goland" <[email-masked]<mailto:[email-masked]>> wrote:
I've been noodling [1] a lot about full delegation in OAuth [2] and one of the issues that came out of that was the need for discovering both the location and realm of an endpoint's token server. But at least for my use cases (which consist of walking up to a service and making an options request and getting back a www-authenticate header) all I need back is a realm and a token server URL. In other words just having one argument added to our www-authenticate header would be enough to solve the case where someone wants to walk up to a service and find out where its token server is. Does that really need its own spec? Or can we just add an argument to www-authenticate in the current spec?
        Thanks,
                Yaron

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> To: Manger, James H; OAuth WG ([email-masked]<mailto:[email-masked]>)
> > To: Eran Hammer-Lahav; OAuth WG ([email-masked]<mailto:[email-masked]>)
> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: "William Mills" <[email-masked]>
Date: Mon, 28 Jun 2010 15:29:37 -0700

In the SASL stuff I'm working on I was presuming I'd use the
WWW-Authenticate header for returning the discovery info.

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Yaron Goland
	Sent: Monday, June 28, 2010 3:10 PM
	To: Torsten Lodderstedt
	Cc: OAuth WG
	Subject: Re: [OAUTH-WG] OAuth discovery draft?

	I believe that GET should be used to return the resource's state
and its OAuth token endpoint is just a tiny part of that state. When we
want to return part of the state we typically use either explicit
headers (a la byte ranges) or a query parameter. Content-types should, I
think, just control the syntax of what is returned, not the subset of
data it contains. So I have to admit that I really don't like using GET
for this sort of scenario.

	OPTIONS is actually the officially blessed way to walk up to a
resource, knock on the front door and ask 'what are you and what can you
do?' So it seems to me we should start with OPTIONS. But this does bring
up a problem - nobody ever really defined a response body for OPTIONS.
RFC 2616 explicitly defined the legality of such a body but no standard
was defined for what the body should look like. This is an issue because
if someone does define a body for OPTIONS then they really need to do so
in a way that other standards can build on top of.

	So we have a choice when it comes to using OPTIONS. We can
return data in the header in which case all we have to do is just define
the header, submit the RFC and call it day. Or we can use the body but
in that case we probably need to write one spec to define a generic way
to return data in OPTIONS response bodies (e.g. how do different OPTIONS
responses live together?) and get that standardized. Then we can write a
second RFC to define how our specific data would be carried in OPTIONS.

	                Thoughts?

	                                Yaron

	I think it should be possible to discover a resource's OAuth
server and its capabilities using a direct Discovery request. I don't
think a WWW-Authenticate Header is the right representation for this
kind of data. What about a JSON or XML document returned in response to
an OPTIONS request (as you suggested) or a GET request with a certain
content type in its ACCEPT Header?

	regards,

	Torsten. 

	Am 23.06.2010 um 20:20 schrieb Yaron Goland
<[email-masked]>:

		No objections on my part. I would rather have a smaller
core spec with features that everyone agrees on.

		BTW, a thought for the discovery draft - RFC 2616/2617
only defines www-authenticate's semantics in the context of a 401. It's
unclear from the draft what it would mean to return a www-authenticate
header on a 200 response. The reason I care about this is that I think
it makes sense that if someone wants to talk to an endpoint they know
supports OAuth and need to know where their token issuer location is
they would want to fire off an OPTIONS request to the resource and find
out from the response where the issuer is and what realm is being used.
It seems to me that the simplest way to solve this problem is to just
return www-authenticate on a 200 response to an OPTIONS request. 

		                Thoughts?

		                                Thanks,

		                                                Yaron

		I think the core work is pretty stable now, unlike the
discovery bits which (while simple) are not enjoying the same level of
consensus. I think it is much more practical to propose them as a
separate document and perhaps consider merging them later on when they
reach an equal level of stability. But overall, I'm not too worries
about multiple documents.
		
		EHL

		On 6/23/10 11:00 AM, "Yaron Goland"
<[email-masked]> wrote:

		I've been noodling [1] a lot about full delegation in
OAuth [2] and one of the issues that came out of that was the need for
discovering both the location and realm of an endpoint's token server.
But at least for my use cases (which consist of walking up to a service
and making an options request and getting back a www-authenticate
header) all I need back is a realm and a token server URL. In other
words just having one argument added to our www-authenticate header
would be enough to solve the case where someone wants to walk up to a
service and find out where its token server is. Does that really need
its own spec? Or can we just add an argument to www-authenticate in the
current spec?
		        Thanks,
		                Yaron
		
		[1] See http://www.goland.org/oauthgenericdelegation/
for an overview of my thinking on full delegation in OAuth. At the very
end are links to a bunch of other much more in-depth articles on
particular subjects touched on in the main article.
		
		[2] I define 'full delegation' as "User X of Service Y
grants permission Z to User A of Service B". Currently OAuth requires X
== A. In the future I hope to see extensions to OAuth that enable what
I'm terming 'full delegation'. But personally I'm really happy that
OAuth has the X==A restriction. It simplifies a whole host of issues and
satisfies a really important use case.
		
		> From: [email-masked]
[mailto:[email-masked]] On Behalf
<http://wiki.openid.net/Future-OpenID-Technical-Requirements> says:
		> > implementing", "no update is expected", "replaced by
the OAuth 2.0
		> effort".

---

From: Yaron Goland <[email-masked]>
Date: Tue, 29 Jun 2010 19:28:29 +0000

This then goes back to one of my original posts which is - Is www-authenticate legal on a non-401 response? I honestly don't know.

From: William Mills [mailto:[email-masked]]
Sent: Monday, June 28, 2010 3:30 PM
To: Yaron Goland; Torsten Lodderstedt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] OAuth discovery draft?

In the SASL stuff I'm working on I was presuming I'd use the WWW-Authenticate header for returning the discovery info.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Goland
Sent: Monday, June 28, 2010 3:10 PM
To: Torsten Lodderstedt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth discovery draft?
I believe that GET should be used to return the resource's state and its OAuth token endpoint is just a tiny part of that state. When we want to return part of the state we typically use either explicit headers (a la byte ranges) or a query parameter. Content-types should, I think, just control the syntax of what is returned, not the subset of data it contains. So I have to admit that I really don't like using GET for this sort of scenario.

OPTIONS is actually the officially blessed way to walk up to a resource, knock on the front door and ask 'what are you and what can you do?' So it seems to me we should start with OPTIONS. But this does bring up a problem - nobody ever really defined a response body for OPTIONS. RFC 2616 explicitly defined the legality of such a body but no standard was defined for what the body should look like. This is an issue because if someone does define a body for OPTIONS then they really need to do so in a way that other standards can build on top of.

                Thoughts?

                                Yaron

regards,
Torsten.

                Thoughts?

                                Thanks,

                                                Yaron

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 29 Jun 2010 12:31:16 -0700

It is. 401 without it is not.

The discovery spec should spell out how to include it with a 200 response when additional, private data is available.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Goland
Sent: Tuesday, June 29, 2010 12:28 PM
To: William Mills; Torsten Lodderstedt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth discovery draft?

                Thoughts?

                                Yaron

regards,
Torsten.

                Thoughts?

                                Thanks,

                                                Yaron

EHL