Subject: [OAUTH-WG] OAuth2 scheme (was Error registry proposal (round 3))

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 6 Apr 2011 16:35:09 -0700

Well... Can't say I didn't see this coming :)

The issue is not simply about putting a section back, but about the overall protocol architecture and how it complies with HTTP.

For example, taking the MAC draft, how do you envision the resource server responding to a failed authentication attempt? A 401 response and what header(s)? WWW-Authenticate with 'OAuth2' scheme? 'MAC' scheme? Both?

Also see: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/78

You might think you are asking for a simple feature, but this is moving the protocol from a purely authorization protocol to an authentication protocol which is what the split of the token types was designed to accomplish.

What I am asking for is to provide full examples of how you envision the OAuth2 scheme to work in practice, especially considering the MAC draft. Assume that the MAC draft, since it is defined as a general purpose scheme, is not going to change (for the sake of argument only), do you envision it being used differently when combines with an OAuth access token? That would be bad.

I removed the WWW-Authenticate header and the OAuth2 scheme because it served no purpose and no one demonstrated how it will be actually used. WRAP is not a good example because WRAP is a closed protocol (just like OAuth 1.0). There is no way to add new authentication schemes to WRAP and in that context, it makes sense to define a scheme. But here it will mean moving backwards to a protocol where only OAuth-specific authentication schemes can be used, and they all must be defined as extensions of this master OAuth2 scheme.

There was pretty good consensus not to define a master scheme with sub schemes. That is well documented on the list. This thread included the discussion about using a common prefix for scheme names, etc. Hope we don't have to repeat that.

So if OAuth2 is not a master scheme for all other scheme to be defined as sub-schemes, what is it? I don't have an answer and we kinda need one to put such a scheme back in the document.

EHL

From: Mike Jones [mailto:[email-masked]]
Sent: Wednesday, April 06, 2011 4:13 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Error registry proposal (round 3)

Actually, you correctly point out (indirectly), that this is related to one of the open issues that needs to be resolved to complete the specs when you wrote "For such a registry to be useful, you also need to standardize the authentication header across all schemes and define a standard parameter used to deliver such error codes".

This open issue (which there wasn't time to discuss during last week's meeting) was the removal of the WWW-Authenticate Response Header.  This feature was present in WRAP and earlier OAuth drafts but was removed without a clear consensus to do so.  And indeed, during our private discussions on how the draft should be split, at that time, you took the position that the WWW-Authenticate response should remain in the framework spec.

The result has been that there is different and incompatible WWW-Authenticate response functionality in multiple related drafts - specifically draft-hammer-oauth-v2-mac-token-02 and draft-ietf-oauth-v2-bearer-04.  Interoperability and developers would both be better served by moving this functionality back into the core. I don't believe that each related OAuth specification should have to separately specify this functionality.  As this was not discussed during last week's meeting, a consensus call from the chairs may be necessary to resolve this issue.

                                                                -- Mike

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Wednesday, April 06, 2011 3:58 PM
To: Mike Jones; OAuth WG
Subject: RE: Error registry proposal (round 3)

Putting aside my view that a registry for resource server error responses across HTTP authentication schemes isn't very useful or interesting, I don't have an objection to the bearer token specification defining such general purpose registry. In a way, it is similar to the error response headers defined by Digest, only never made generally applicable.

The difference in our approaches is that I don't consider the bearer token or mac token specs to be extensions of the v2 spec, but fully specified HTTP authentication schemes with OAuth 2.0 binding (i.e. the access token type registration). Because of that, I don't think the v2 spec is the right place for such a registry, which is really about HTTP authentication schemes and not OAuth. Therefore, I think it will be more confusing to put such a registry in v2.

I'll give you an example. Suppose someone will define a Digest access token type. When issuing one, the server will send an access token (to be used as username) and a secret (to be used as password). To use such a token, the client will use the HTTP Digest scheme (as is). Digest defines its own set and method or specifying error code. Would you expect those to be registered in your proposed registry? I would assume not.

For such a registry to be useful, you also need to standardize the authentication header across all schemes and define a standard parameter used to deliver such error codes. However, we already moved away from that design by defining separate HTTP authentication schemes for each token type.

But again, I don't have an objection to such a registry defined in the bearer token spec. I have no intentions of using it for any HTTP authentication scheme I plan to author.

EHL

From: Mike Jones [mailto:[email-masked]]
Sent: Wednesday, April 06, 2011 3:39 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Error registry proposal (round 3)

The problem with that situation is that it doesn't provide a central registry for resource server error responses across specs, unlike the other kinds of OAuth error responses.  I could define that registry in the bearer token spec, but it would be less confusing to unify it with the proposed registry in the framework spec.  I suspect developers would thank us for doing that.

What do you say?

                                                                -- Mike

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Wednesday, April 06, 2011 2:58 PM
To: Mike Jones; OAuth WG
Subject: RE: Error registry proposal (round 3)

Hi Mike,

This is intentional. The error registry defined in v2 is not designed to record errors for the protected resource endpoint response or the WWW-Authenticate response header when used with the Bearer token scheme (or any other scheme).

The only purpose of the registry is to avoid name collisions between two errors used differently with the v2 specification. Since errors used with the Bearer token scheme will never appear in the same place as the v2 endpoints, there is no need for combining these two registries.

If the bearer token specification requires error extensibility, you should retain the registry there and limit it to just the protected resource response space. Ideally, you would limit it to just the WWW-Authenticate header 'error' parameter when used with the Bearer scheme. The MAC scheme does not use error codes, but instead, relies fully on HTTP status code since no additional error conditions were identified.

Also, since your ABNF permits adding additional Authorization header parameters, you might want to consider defining a process for doing that, if you are going to define an error registry. Currently, to add additional parameters, one has to update the Bearer token RFC, in contrast to simply registering a new error code (which is likely to come out of a new parameter).

EHL

From: Mike Jones [mailto:[email-masked]]
Sent: Wednesday, April 06, 2011 2:25 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Error registry proposal (round 3)

Thanks for writing this up, Eran.  I believe that this is a step in the right direction.

Wearing my Bearer Token spec editor hat, I just tried to go through the exercise of editing my document to use the registry in draft 15 to register the errors defined in the bearer token spec and I hit a roadblock.  Specifically, while the errors defined by my spec are returned by resource servers (flow F in Figure 1), the registry defined by draft 15 does not include "resource server error response" in the "error usage location" list.  Can you please add this additional error usage location so that the registry can be used by the bearer token specification?

At that point, I believe we'll be able to close the open issue about the need for an error registry, and I'll update my draft accordingly.

                                                                Thank you,
                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, April 05, 2011 3:52 PM
To: OAuth WG
Subject: [OAUTH-WG] Error registry proposal (round 3)

The following is my new proposal, based on Mike Jones' and my earlier proposals. It is basically a combination of the two.

This proposal does not allow defining new error codes unless another extension is involved (new grant type, request parameter, token type). The reason for not defining an open ended error registry is that defining new error codes for existing implementations is bad for interoperability and can lead to unexpected results (developers not taking into account receiving a new error when talking to a compliant 2.0 server). We don't have any use cases for defining such new errors for the v2 specification. New errors only come from extensions and must be defined in that context.

I have applied to changes to the -14 draft and clearly marked them with [[Pending Consensus]] so that there is no issue with removing them or changing them later.

---

Add to the error codes list in sections 4.1.2.1 and 4.2.2.1:

         a 4xx or 5xx HTTP status code (except for 400 and 401)
               The authorization server MAY set the "error" parameter
               value to a numerical HTTP status code from the 4xx or 5xx
               range, with the exception of the 400 (Bad Request) and
               401 (Unauthorized) status codes.  For example, if the
               service is temporarily unavailable, the authorization
               server MAY return an error response with "error" set to
               "503".

Add a new section 8.4:

8.4.  Defining Additional Error Codes

   In cases where protocol extensions (i.e. access token types,

   extension parameters, or extension grant types) require additional

   error codes to be used with the authorization code grant error

   response (Section 4.1.2.1), the implicit grant error response

   (Section 4.2.2.1), or the token error response (Section 5.2), such

   error codes MAY be defined.

   Extension error codes MUST be registered (following the procedures in

   Section 10.3) if the extension they are used in conjunction with is

   registered.  Additional error codes used with unregistered extensions

   MAY be registered.

   Error codes MUST conform to the error-code ABNF, and SHOULD be

   prefixed by an identifying name when possible.  For example, an error

   identifying an invalid value set to the extension parameter "example"

   should be named "example_invalid".

     error-code   = ALPHA *error-char

     error-char   = "-" / "." / "_" / DIGIT / ALPHA

Add a new section 10.3:

10.3.  The OAuth Extensions Error Registry

   This specification establishes the OAuth extensions error registry.

   Additional error codes used together with other protocol extensions

   (i.e. extension grant types, access token types, or extension

   parameters) are registered on the advice of one or more Designated

   Experts (appointed by the IESG or their delegate), with a

   Specification Required (using terminology from [RFC5226]).  However,

   to allow for the allocation of values prior to publication, the

   Designated Expert(s) may approve registration once they are satisfied

   that such a specification will be published.

   Registration requests should be sent to the [TBD]@ietf.org mailing

   list for review and comment, with an appropriate subject (e.g.,

   "Request for error code: example"). [[ Note to RFC-EDITOR: The name

   of the mailing list should be determined in consultation with the

   IESG and IANA.  Suggested name: oauth-ext-review. ]]

   Within at most 14 days of the request, the Designated Expert(s) will

   either approve or deny the registration request, communicating this

   decision to the review list and IANA.  Denials should include an

   explanation and, if applicable, suggestions as to how to make the

   request successful.

   Decisions (or lack thereof) made by the Designated Expert can be

   first appealed to Application Area Directors (contactable using

   [email-masked]<mailto:[email-masked]> email address or directly by looking up their

   email addresses on http://www.iesg.org/ website) and, if the

   appellant is not satisfied with the response, to the full IESG (using

   the [email-masked]<mailto:[email-masked]> mailing list).

   IANA should only accept registry updates from the Designated

   Expert(s), and should direct all requests for registration to the

   review mailing list.

10.3.1.  Registration Template

   Error name:

      The name requested (e.g., "example").

   Error usage location:

      The location(s) where the error can be used.  The possible

      locations are: authorization code grant error response

      (Section 4.1.2.1), implicit grant error response

      (Section 4.2.2.1), or token error response (Section 5.2).

   Related protocol extension:

      The name of the extension grant type, access token type, or

      extension parameter, the error code is used in conjunction with.

   Change controller:

      For standards-track RFCs, state "IETF".  For others, give the name

      of the responsible party.  Other details (e.g., postal address,

      e-mail address, home page URI) may also be included.

   Specification document(s):

      Reference to document that specifies the error code, preferably

      including a URI that can be used to retrieve a copy of the

      document.  An indication of the relevant sections may also be

      included, but is not required.

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 8 Apr 2011 11:48:49 +1000

We should define a "WWW-Authenticate: OAuth2 ..." response header - not to encompass the MAC, Bearer, and any other generic HTTP authentication scheme, but as a way for a server to tell the client that it can perform an OAuth2 get-a-token flow to gain access. When the sort of OAuth2 flow depends on the error with a current token (eg expired vs invalid) then the "WWW-Authenticate: OAuth2 ..." response header needs to reflect this. It could do so be including an error code. A better, more direct, approach is to explicitly identify "refresh flow" and/or "user-delegation flow" and/or "assertion flow" etc.

Bearer or OAuth2 WWW-Authenticate response header?

The rule should be:

#1. If the client can fix an error by sending an "Authorization: Bearer ..." request header (or the query or POST alternative) then the server should return "WWW-Authenticate: Bearer ...".

#2. If the client can fix an error by performing an OAuth2 flow at an authorization server then the resource server should return "WWW-Authenticate: OAuth2 ...".

The server can return both response headers if both options are possible.

There is no point in re-presenting a rejected Bearer token so #1 isn't that useful. It could be appropriate if no token was presented as the client might have a token, but didn't know this resource needed it. It might be appropriate if a client presented a token with insufficient scope as the client might have another token with the right scope so "WWW-Authenticate: Bearer scope=..." could help. #1 is not really necessary when a presented token is invalid or expired as the client needs to get a new one (eg using an OAuth2 flow that is outside the scope of the Bearer scheme).

I don't think an error code in a "WWW-Authenticate: Bearer ..." response helps a client retry the request with a "Authorization: Bearer ..." header that will work.

An error code might help a client choose the right OAuth2 flow (eg refresh vs new user-delegation) so it might have a place in #2, a "WWW-Authenticate: OAuth2 ..." response header.

Eran said to Mike:

> Alternatively, if you have use cases or requirements for introducing just the WWW-Authenticate side of an OAuth2 authorization scheme (your open issue), which includes an 'error' attribute for use with the proposed registry, please present those and explain how it will work alongside the Bearer and MAC schemes (as currently drafted).

The "discovery" use-case in this email warrants the WWW-Authenticate side of an OAuth2 scheme.

An error attribute (plus a registry) might help, but we need the rest of the details of the response header first.

It works well alongside Bearer and MAC schemes: a "WWW-Auth.: OAuth2" response points to OAuth2 flows the client can try; a "WWW-Auth.: MAC/Bearer" response points to retrying a request with "Authz: MAC/Bearer". Even when a client is given multiple options it will know which to choose based on its context (eg if it doesn't have another Bearer token it will ignore the "WWW-Auth: Bearer" response and follow the "WWW-Auth: OAuth2" response).

--

James Manger

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 7 Apr 2011 19:00:53 -0700 (PDT)

In the SASL mechanism draft spec where we went with that is to use LINK headers.  See http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth-01 if you want to take a look.  WWW-Authenticate headers return the supported authentication schemes and LINK headers tell you there are OAuth endpoints you can interact with.

It's a swag at discovery in band, might work here too.

________________________________
From: "Manger, James H" <[email-masked]>
To: OAuth WG <[email-masked]>
Sent: Thursday, April 7, 2011 6:48 PM
Subject: Re: [OAUTH-WG] OAuth2 scheme

We should define a “WWW-Authenticate: OAuth2 …” response header – not to encompass the MAC, Bearer, and any other generic HTTP authentication scheme, but as a way for a server to tell the client that it can perform an OAuth2 get-a-token flow to gain access. When the sort of OAuth2 flow depends on the error with a current token (eg expired vs invalid) then the “WWW-Authenticate: OAuth2 …” response header needs to reflect this. It could do so be including an error code. A better, more direct, approach is to explicitly identify “refresh flow” and/or “user-delegation flow” and/or “assertion flow” etc.
 
Bearer or OAuth2 WWW-Authenticate response header?
The rule should be:
#1. If the client can fix an error by sending an “Authorization: Bearer …” request header (or the query or POST alternative) then the server should return “WWW-Authenticate: Bearer …”.
 
#2. If the client can fix an error by performing an OAuth2 flow at an authorization server then the resource server should return “WWW-Authenticate: OAuth2 …”.

There is no point in re-presenting a rejected Bearer token so #1 isn’t that useful. It could be appropriate if no token was presented as the client might have a token, but didn’t know this resource needed it. It might be appropriate if a client presented a token with insufficient scope as the client might have another token with the right scope so “WWW-Authenticate: Bearer scope=…” could help. #1 is not really necessary when a presented token is invalid or expired as the client needs to get a new one (eg using an OAuth2 flow that is outside the scope of the Bearer scheme).
 
I don’t think an error code in a “WWW-Authenticate: Bearer …” response helps a client retry the request with a “Authorization: Bearer …” header that will work.
An error code might help a client choose the right OAuth2 flow (eg refresh vs new user-delegation) so it might have a place in #2, a “WWW-Authenticate: OAuth2 …” response header.
 
Eran said to Mike:
> Alternatively, if you have use cases or requirements for introducing just the WWW-Authenticate side of an OAuth2 authorization scheme (your open issue), which includes an ‘error’ attribute for use with the proposed registry, please present those and explain how it will work alongside the Bearer and MAC schemes (as currently drafted).
 
The “discovery” use-case in this email warrants the WWW-Authenticate side of an OAuth2 scheme.
An error attribute (plus a registry) might help, but we need the rest of the details of the response header first.
It works well alongside Bearer and MAC schemes: a “WWW-Auth.: OAuth2” response points to OAuth2 flows the client can try; a “WWW-Auth.: MAC/Bearer” response points to retrying a request with “Authz: MAC/Bearer”. Even when a client is given multiple options it will know which to choose based on its context (eg if it doesn’t have another Bearer token it will ignore the “WWW-Auth: Bearer” response and follow the “WWW-Auth: OAuth2” response).

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 7 Apr 2011 19:01:49 -0700

Chairs - see request inline.

Hi James,

The use case you proposed for an OAuth2 scheme is not about token authentication at all but about relaying authorization server discovery information only. This use case is completely within the realm of discovery, and that is out of scope.

There is nothing to prevent another document from taking the time (as you indicated is necessary) to figure out exactly what the requirements are for such a scheme, and to thoroughly map them into the right set of attributes. I believe discovery is still very much undefined and cannot be figured out without significant deployment experience for OAuth 2.0, as well as some stabilization of new grant types and other extensions.

Chairs - I would like to ask that you declare all discovery requirements and use cases out of scope for v2 and the working group at this point.

---

As for the error code registry and the request Mike posted, I do not think your use case has much to do with the goal Mike has with his registry proposal. Mike's proposal is for v2 to define an error registry for use with an error attribute across different HTTP schemes such as Bearer and MAC, and for that to make sense, we need to define an OAuth2 scheme that *replaces* the Bearer and MAC schemes - something you agree we should not do.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Thursday, April 07, 2011 6:49 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] OAuth2 scheme

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 7 Apr 2011 19:03:30 -0700

I agree that Link headers are much better fit for relaying discovery information than a half HTTP authentication scheme. Overall, I find James’ proposal to be too complex and not intuitive to people familiar with existing HTTP authentication schemes (it is novel and well thought, and it does work, just not as most people expect discovery to).

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of William J. Mills
Sent: Thursday, April 07, 2011 7:01 PM
To: Manger, James H; OAuth WG
Subject: Re: [OAUTH-WG] OAuth2 scheme

--
James Manger

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

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 8 Apr 2011 16:47:12 +1000

A WWW-Auth header is a server’s security statement about how to gain access.

A Link header is a server’s statement of a relationship to another URI.

I find the Links+WWW-Auth approach more complex, less intuitive, and not as good a match for HTTP semantics.

Each WWW-Auth header in my approach is a standalone statement of a path the client can take to gain access. When an OAuth2 flow is a possible path, include a “WWW-Auth: OAuth2 …” response header.

Using Links+WWW-Auth requires interpreting a combination of headers.

draft-mills-kitten-sasl-oauth-01#section-7.2 has an example of a error response:

   HTTP/1.1 401 Unauthorized

   WWW-Authenticate: BEARER realm="example.com"

   Link: <https://login.yahoo.com/oauth> rel="oauth2-authenticator"

   Link: <https://login.yahoo.com/oauth> rel="ouath2-token"

A Link header is a nice, clean, intuitive approach for delivering a static token endpoint URI.

However, that is not actually what a client needs in an HTTP error response. The client needs to know what to do next, in the context of this request and the credentials it included. That is more dynamic.

Consider the error codes that Mike Jones & others want to standardise/register across authentication schemes. They are needed to know which OAuth2 flow to perform (eg try a refresh if the token has expired; redo user delegation if more scope is needed).

Should the error code go in an OAuth2 Link header? That feels a bit strange. It requires extra parameters to be defined for specific Link relations (possible, but not as intuitive). No one has suggested this, though I think it is the correct design if Links+WWW-Auth is used.

The other option is to put the error code in the WWW-Auth header for a specific scheme. Which scheme? Every scheme for which OAuth2 could deliver a token now needs to be modified so its error response can include OAuth2-specific details. That is feasible for the Bearer scheme, but not generally. There is no WWW-Auth header to put the error code in if, say, the TLS layer is used for client authentication (eg TLS-PSK or TLS-SRP or …).

This might be a trivial issue if OAuth2 is only ever used with the Bearer HTTP schemes – but it does illustrate a design flaw: one more unnecessary strong coupling between the authentication mechanism and the OAuth2 delegation/authorization flows.

--

James Manger

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Friday, 8 April 2011 12:04 PM
To: William J. Mills; Manger, James H; OAuth WG
Subject: RE: [OAUTH-WG] OAuth2 scheme

EHL

  _____

The rule should be:

--

James Manger

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 7 Apr 2011 23:57:39 -0700 (PDT)

I found when I started trying to put this into WWW-Authenticate header it ended up with a lot of extensions and parsing.  Link headers make sense to me in that the client that needs to know where the authenticator for a site is can look at the linking relationships, and a registry already exists for defining them because we're extending the current model that pretty much fits.

We need to convey the same information no matter what we do.

As for error codes, I think that's orthogonal to the discovery information.  

-bill

________________________________
From: "Manger, James H" <[email-masked]>
To: Eran Hammer-Lahav <[email-masked]>; William J. Mills <[email-masked]>; OAuth WG <[email-masked]>
Sent: Thursday, April 7, 2011 11:47 PM
Subject: RE: [OAUTH-WG] OAuth2 scheme

 

 

--
James Manger

From:Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Friday, 8 April 2011 12:04 PM
To: William J. Mills; Manger, James H; OAuth WG
Subject: RE: [OAUTH-WG] OAuth2 scheme

EHL
 
From:[email-masked] [mailto:[email-masked]] On Behalf Of William J. Mills
Sent: Thursday, April 07, 2011 7:01 PM
To: Manger, James H; OAuth WG
Subject: Re: [OAUTH-WG] OAuth2 scheme
 
In the SASL mechanism draft spec where we went with that is to use LINK headers.  See
http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth-01 if you want to take a look.  WWW-Authenticate headers return the supported authentication schemes and LINK headers tell you there are OAuth endpoints you can interact with.

 
From:"Manger, James H" <[email-masked]>
To: OAuth WG <[email-masked]>
Sent: Thursday, April 7, 2011 6:48 PM
Subject: Re: [OAUTH-WG] OAuth2 scheme

 

 

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 8 Apr 2011 17:17:28 +1000

[Sorry, I didn't see this email before I sent my last one]

> As for the error code registry and the request Mike posted, I do not think your use case has much to do with the goal Mike has with his registry proposal. Mike's proposal is for v2 to define an err…

An error code is part of discovery - it lets a client app "discover" what it needs to do next to gain access.

We can have separate discovery of fairly static server capabilities and endpoints and call that out of scope for v2.

However, we still need dynamic discovery of which OAuth2 flow a client should do after a particular HTTP resource request fails. This is related to error codes so needs to be as in-scope as error codes are. Indicating which OAuth2 flow to perform should be OAuth2-specific, not kludged onto every (independent) authentication scheme.

P.S. I still absolutely agree that we should NOT define one OAuth2 scheme that replaces Bearer and MAC.

--

James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 8 Apr 2011 20:56:09 -0700

Thanks James.

I think overall your proposal is a good direction. I think the combination of Link and WWW-Authenticate headers (static/dynamic) discovery is interesting.

If you have the time, I would love to see an I-D defining the OAuth2 authentication scheme (partial as you defined it) with clear usage and processing rules for using it with other HTTP schemes. While this is clearly not within our scope, progressing such a draft now on the side makes a lot of sense to me.

EHL

From: Manger, James H [mailto:[email-masked]]
Sent: Friday, April 08, 2011 12:17 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: OAuth2 scheme

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 12 Apr 2011 16:00:31 +1000

I will have a go writing an I-D defining an OAuth2 WWW-Auth response header... though it will not be for at least a fortnight :-(

--

James Manger

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Saturday, 9 April 2011 1:56 PM
To: Manger, James H; OAuth WG
Subject: RE: OAuth2 scheme

Thanks James.

EHL