Re: [OAUTH-WG] OAuth2 scheme

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

Re: [OAUTH-WG] OAuth2 scheme

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

Re: [OAUTH-WG] Flowchart for legs of OAuth

Hi Skylar, Am 06.04.2011 18:02, schrieb Skylar Woodward: Well, I should elaborate. The method of authorization is open to the client, and in this case (Kiva), MAC tokens are being used. The client authenticates on the access_token request by presenting a MAC authentication header. Creating th

Re: [OAUTH-WG] OAuth2 scheme

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 wor

Re: [OAUTH-WG] OAuth2 scheme

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 noth

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

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

[OAUTH-WG] In the spirit of compromise

Having thought about it over night and discussed it, I'm willing to drop my objection the WWW-Authenticate response not being in the framework specification, so as to close an open issue that could delay completion of the specifications. Eran, in return, I'd like to ask you to drop your objecti

Re: [OAUTH-WG] Security Considerations Section Proposal -02

fine with me, you can obtain the source from https://github.com/tlodderstedt/oauth2/raw/master/draft-lodderstedt-oauth-securityconsiderations.xml Am 07.04.2011 16:10, schrieb Eran Hammer-Lahav: I think it would be best to publish -16 immediately with this text, mark it as pending consensus, an

Re: [OAUTH-WG] Security Considerations Section Proposal -02

Please hold off on editorial feedback. Trying to figure out section numbers after the move is just too annoying. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Oleg Gryb > Sent: Thursday, April 07, 2011 9:37 AM > To: Torsten Lodders

Re: [OAUTH-WG] Security Considerations Section Proposal -02

Definitions "they can seamlessly make use of it capabilities" - its? 2.3 "Application developers MUST NOT store access tokens in non-transient memory". What is non-transient memory? Is non-persistent cookie non-transient? Do we know how all browsers store their non-persistent cookies? What if

Re: [OAUTH-WG] Security Considerations Section Proposal -02

I think it would be best to publish -16 immediately with this text, mark it as pending consensus, and continue with a single document. This will make it easier for new readers as well as for everyone else. I will push it out in a couple of hours. EHL > -Original Message- > From: oauth-

Re: [OAUTH-WG] draft-15 editorials

Hi James, sorry I didnt see your earlier suggestion. And your text works for me - just looking for text that hints at something beyond delegation thanks paul On 4/6/11 11:15 PM, Manger, James H wrote: Paul, The draft-15.1 abstract is just the first sentence of the abstract I suggested la

[OAUTH-WG] Security Considerations Section Proposal -02

Hi all, I just posted a new revision of the proposed text for the core draft's security considerations section (http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02). The text makes some strong statements wrt client secrets/authentication, HTTPS, refresh tokens and ot