[Ietf-http-auth] Implementation likelihood?

[Joe Orton]

On Wed, Nov 23, 2005 at 12:46:36PM -0600, Nicolas Williams wrote:
> Note that these two motivations are one and the same: we just want more
> choices of remote authentication mechanism in HTTP applications.
>
> Sometimes the choice will be Kerberos V, sometimes it will be a
> SAML-based mechanism, sometimes it will be a PKIX-based mechanism,
> sometimes it will be some password digest mechanism, sometimes it will
> be a challenge/response token mechanism, etc...  Whatever is appropriate
> for any given {user, service}.  Kerberos V may well dominate intranets
> sure, while SAML and password mechanisms domainate on the wider
> Internet, but that's not important -- having these choices is.
> 
> However, whatever we do we should have to do it no more than once: it
> should be possible to add new mechanisms without having to revise the
> base HTTP authentication specs again.

I'm not sure exactly what you're getting at there: it's already possible 
to define and deploy new HTTP auth schemes without changing RFC 2616 or 
2617 one bit.

But an HTTP auth scheme can only be an HTTP auth scheme, and if what you 
actually want to do is to negotiate a new transport layer (which you 
really do with any Kerberos solution, be that SASL or GSSAPI) then you 
need a spec for an HTTP-over-SASL or an HTTP-over-GSSAPI transport 
layer, not merely an HTTP auth scheme.

joe