use of IAN for driving the birrel/lampson handoff rule; different semantics to the current IAN "issue" on the books

Consider letting the IAN URI in a user's [self-signed] client cert point at the server _cert_ of the https channel over which the subject's profile document MUST be released
 
If an https IAN URI with an https scheme is present in the client cert, the resource server MUST contact the profile card's webserver using https (or http over SSLVPN) , obtain the server cert from a full SSL handshake, and confirm that the server cert "matches" the entity identified in the IAN.
 
There seems no reason why the IAN cannot be a URI to the web server's own FOAF card. Let me call such an IAN an "issuer-webid", distinct from a 'subject-webid'. Let the "matching" (above) be performed while peforming the current the subject webid handling procedure, using the cert ontology for double duty  - now to enforce that the server cert's public key matches values found in the issuer's graph. 
 
E.g. if the client cert has IAN https://cloud.com/#webserver, then the proposed "issuer-matching" procedure dereferences the associated graph over https (or http over SSLVPN) and confirms that the server cert's public key is listed in the graph of #webserver (using the SPARQL query implied by the cert ontology relations). issuer-matching also requires the resource server to confirm that the channel's server cert affirms control over the domain-name cloud.com (using suitable cert fields, including CNs with optional wild card rules, and SAN).
 
This kind of "referall-chasing" centered on the resource server is obviously iterative, since the server cert (above) may have its own IAN URI, which points to another https channel bearing the profile doc of its issuer.
 
Note, none of this interferes with PKI style chaining, used in the case that a third-party CA issues the client cert with the subject-webids. The third party CA use case still gets to use the X.509 authority-key-identifier to label the parent cert in the certificate chain, used when performing the logic of "certificate path processing" per PKIX. A cert chain is distinct from a referall-chain due to webids in IANs.
 
Having computed a closed set of foaf cards by backtracking along the https channels speaking-for the profile docs, the resource server might now perform a query to require that each issuer's graph _follows_ the subject id of the next card "in sequence".
 
This essentially implements webid-based discovery of "trust paths" linking https channel speakers. Even though the subject certs may be hierarchically governed (by the usual multi-element X.509 cert chain with AKI backpointers), the procedure enforces a "handoff rule" that applies during reliance on the profile documents, where there is a chain of handoffs between nodes in URI space as discovered by interative backtracking.
 
Peter.