Let’s use the certificate and webid profile I cannot actually change (since I have lost control over the site). It is thus highly stable, for testing purposes. It’s at http://yorkporc.blogspot.com/
First, lets qualify that the test assumptions are working:
1) Does a SSL handshake work with my test browser, and is the certificate delivered having form that meets the parsing standards for webid profile certificates?
Yes. Evidently we can make a certificate with a name it in, and the name is an ASN.1 value called SAN (for short), in its URIName variant. This certificate was minted using an RPC service (Microsoft certificate services) that underlies Microsoft Certificate Server (for the web). It has 3 URIs. (The web site variety of the Microsoft certificate service only mints one URI in the SAN – which is why we used an alternative more flexible UI interface to the service). We can expect Webid realm to handle this cert, being reasonably (if not 100%) conforming. It is not self-signed.
2) Can the triples be parsed?
From the evidence of the test with https://auth.fcns.eu/auth/index.php?verbose=on, yes the triples can be consumed and handled as (subject predicate object) values.
3) Can one query the triples?
The webid spec specified a particular sparql query, that forms the basis of the security enforcing feature. It asks whether a formatted string of an RSA modulus from the inbound certificate presented via the SSL handshake protocol matches with certain values triples, recently read from the profile.
Does the http://yorkporc2.blogspot.com/ profile pass this standard ASK query?
Lets test, using ASK query.
It says true.
4) Lets summarize that the 3 core conditions are ALL true. A profile exists with syntax that can be read. A certificate exists with name that refers to the profile. A query exists that matches values in the certificate to values in the profile.
What now happens when we perform the same experiment with all 3 assumptions at WebID Realm?
Using the link to “Only with Certificate” we get a certificate picker dialog – suggesting we are partly through a run of the SSL Handshake protocol. It is strange that the address bar says http:… (vs https://).
We authorize release of the certificate and use of the private key, using OK.
But, do look at the URI in the address bar in the resulting page. It doesn’t say http.
On releasing these dialogs, we get a 403 denied status:
What do we make of this, remembering that our browser is NOT at (and is at less than) retail settings – so as to maximize the likelihood of interworking during pre-QA development.
There is evidence of an SSL tunnel, formed correctly. And there is, as required, a server certificate.
We see a list of the SAN URIs, which implies that the site has received the client certificate and parsed it for the SAN URI fields – since all 3 are presented.
From the exception reports, the site is correctly determining a sub-test : that one the URIs does not reference a document on the web (despite the claim).
We also see that the address bar has what one would expect, with https.
Finally, we do another trial, this time I get a logon session:
The webid claim is not of my making, and the depiction of a drama queen at least fits the persona. Where these facts come from (technically), I don’t know