Re: [OAUTH-WG] OAuth2 scheme

[Eran Hammer-Lahav <[e-mail]>]

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:[e-mail]]
Sent: Friday, April 08, 2011 12:17 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: OAuth2 scheme

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

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


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