issue of initiating client auth for parallel SSL sessionids

Because of the history of FOAF+SSL, we tend to see demos in which folks goto
a site with http, and then use a login button - guarding a protected region
of the site (or protected modes).

 

I think we need something more general.

 

As one browsers page index.html, should there by a file X referenced (call
it .crt), let the browser connect to its server using https (for that file
GET, only). Presumaly, if browser knows the mime type of .crt, it populates
the accept header with something suitable.

 

What I want is that the validation agent only kick off when it receives a
particular accept header ( induced by a containing page reference that
forced population of that accept header on the resource retrieval attempt).

 

Webid protocol would then run (and setup an SSL sessionid), but https would
not be protecting the connections to other page elements. As one moves
through a site, the SSL sessionid (due to webid protocol) can still guard
access using an authorization logic.

 

What this allows is both classical client authn (using smartcards, in DOD
land) and webid client authn. Now, it easy for the site to maintain 2
distinct SSL sessions, 1 with CA's controlling the selection of certs (which
hits the smartcard/eID) and 1 which does leverages webid.

 

Those SSL connections on the same site supervised by the smartcard/eID SSL
sessionid obviously leverage smartcard/eID's crypto,  doing SSL connections
that offer channel encryption using the *assured* crypto of the card (and
applying CA-based certg chaining authn .merely to protect the channel's
encryption SA). 

 

Those SSL connections on the same site supervised by the webid SSL sessionid
are distinct, influencing "login" authentication and "web sessions" -
driving an authorization engine (perhaps based on federated social network
conceptions)