Which reminds me: Section 3.1 needs to include a clear MUST use TLS when using this authentication method. While this is covered by the requirement to use TLS where OAuth utilized this client authentication scheme (token endpoint), the introduction of client_id and client_secret do invent a new HTTP authentication scheme alongside Basic, and we need to make sure people don't try and apply it elsewhere without TLS (we know someone will).
EHL > -----Original Message----- > From: Peter Saint-Andre [mailto:stpe...@stpeter.im] > Sent: Thursday, April 14, 2011 3:07 PM > To: Eran Hammer-Lahav > Cc: Thomas Hardjono; oauth > Subject: Re: [OAUTH-WG] Revised Section 3 > > On 4/14/11 3:56 PM, Eran Hammer-Lahav wrote: > > <snip/> > > > In practice, this invents a new HTTP authentication scheme. > > Eran, during the WG meeting in Prague you said the same thing, and I > tend to agree. Yes, client authentication is a good thing, but given > that OAuth happens over HTTP I don't see why we can't just use existing > HTTP authentication schemes. If BASIC and DIGEST aren't good enough, > then someone needs to develop a new HTTP authentication scheme. > However > that's not a job for the OAuth WG as far as I can see... > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
