RE: Documenting implicit assumptions?

Be aware that modern browsers using windows libraries can be "combining" mutual auth using certs in TLS channesl with HTTP's digest webauth (which communicates passwords).
 
The critical term there is "combining", vs merely "tunneling" HTTP over TLS as is classical.
 
Combining means that the webauth digest headers are extended, to include TLS channel binding tokens - from server to client (in server only binding tokens) and client to server (for special cases).
 
For the first time, information and state from the "outer" ssl handshake is put within the "inner" http handshake - which takes the form of the ww-auth header pingpongs.
 
Digest auth is very heavily used in the realty version of an http query engine sharing some design elements with the "sparql protocol" - using http URI to communciate queries to a metadata-based search machine. We use its more advanced modes to ensure integrity of the sequence of operations, not only password logon. (Its also been extended in proprietary ways, to exploit RSA.)
 
Arguably, the claim that the world of HTTP knows nothing about its SSL tunnel is no longer true. Its headers can actually be leveraging its secure communication context. Various proposals for more advanced channel binding tokens could more closely tie HTTP to the state of either a ssl handshakes or a custom primitive formed from more than 1 ssl handshake.
 

 
> From: henry.story@bblfish.net
> Date: Wed, 2 Feb 2011 10:50:33 +0100
> CC: msporny@digitalbazaar.com; public-xg-webid@w3.org
> To: nathan@webr3.org
> Subject: Re: Documenting implicit assumptions?
> 
> 
> On 2 Feb 2011, at 02:27, Nathan wrote:
> 
> > Manu Sporny wrote:
> >>>> the notion of public key holder owns to webid uri (on which the protocol
> >>>> is currently predicated) is temporally weak, that is to say, the
> >>>> public/private key holder is not proven to still own / have write
> >>>> permissions to the webid resource.
> >> Control of the profile page is also a vital point in openID : spammers
> >> gaining access to any google/yahoo account can use my openID to login
> >> everywhere on my behalf.
> >> In fact, if classic login can be disabled on the profile hosting site,
> >> WebID can be more secure as it requires an access to one of your
> >> browser certificate to gain control on the profile page.
> > 
> > combined with (optional) SRP it'd be rather wonderful.. I always see WebID as a layered protocol, for instance the last thing I'd want is my bank authorizing access to my account via just WebID, it needs password / secret info transfer as well (thankfully encrypted over the wire thanks to tls)
> 
> +1
> 
> > 
> > Best,
> > 
> > Nathan
> > 
> > srp: http://en.wikipedia.org/wiki/Secure_remote_password_protocol
> 
> 
> > 
> 
> Social Web Architect
> http://bblfish.net/
> 
>