+1 There is the issue of how a client app 'bootstraps' its own credential. It could be that it authenticates by some other RFC (like 2617 Basic Auth), or some other method. E.g. would be nice to have a way for client apps to obtain either the equivalent of client_assertion, or even a MAC token representing just the client security context (a turtles-all-the-way-down approach).
Regardless, I agree this isn't part of the core OAuth specification. Phil [email protected] On 2011-04-14, at 3:06 PM, Peter Saint-Andre wrote: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
