While this shows client certs driving a server-side guard, I’m not sure the SSL Client authentication mechanism is being used. And, webid semantics are restricted to client certs used in the client authentication procedure of the SSL handshake itself (vs. other crypto methods also leveraging certs to authenticate a client).
Should this policy change?
For use with OAUTH2 and its “client” cert methods supproting a simple HTTP URI resource reference, Google’s app site for developers now provisions classical certs and private keys (packaged in a .pfx or .p12 file) for use by consumer-code embedded in server web apps (acting for the browsing user by proxy, typically). Similarly, Azure demonstrates an STS that provisions a client certificate-enabled service principal – that will respond to a similar site asking it to exchange the client cert (and a current signature) for an OAUTH access token (in the form of SWT/JWT).
Why can we not have an STS, working within OAUTH-token minting processes, that consumes the webid cert and its webid (and associated foaf card), when deciding how to mint the OAUTH tokens? Does it have to be an SSL client cert, or can be other certs delivered at the message (http) layer in such as a http header?
Anyways, we seem to have figured some justification for why the as-defined webid client certs don’t work in windows (without first registering them with windows). And, do we now see the fix (once one applies suitable magic?)