windows coding takeaway ... leading to the core'ness of webid

my biggest takeaway from the last year of writing code in modern windows toolcahins enabled me to realize just what a shift (commodity) windows has undergone - all of which enables webid (and its ilk). The Danb diagram shows the space of the ilks. What it didnt indicate was the the web platform (in suich as windows) has evolved per se  in the last year or 2, to "enable" all "the ilks". There is no one ilk to rule them all.
 
As the manchester coding experiment  from foaf+ssl era showed, albeit for traditional servlet culture, is that its not hard to alter the classical CGI model (in its classical servlet incarnation, in tomcat) and ...then evaulate the client cert being presented by the pipline essentially as "additional metadata" ...about the inbound HTTP request. Whether a servlet interceptor or a CGI script uses that metadata, the point is that the evaluation happens after the request is delivered to the CGI service access point. In that world, the client cert is "metadata" ;  and its not "a callback into the pipline" code.
 
In the mdoen windows case, and optionally with IIS or Azure cloud as the listener, things changed about 2 years ago. With the introduction of the WCF programming and the "endpoint hosting" model , IIS as listener can be bound to that "WCF" versus other "protocol-handling-stacks" ...in a way that just was not possible with the single, "traditional" web app. One can now customize the IIS listener to have it host one's own https endpoints - defined and augmented with one's own programmed security behaviors. These behaviours *alter* the http(s) pipeline itself, per secured named URI/resource, allowing a decision from such as the webid validation callbacks aligned with security behaviours to alter the state machine and influence the actions take by the pipeline itself, as "it handles the putative HTTP request", before delivery to CGI land. If webid validation fails, say, then the pipline can produce an HTTP error  code..., or a signed SOAP fault response, or a TCP reset, or (logically) an SSL close or other SSL message (such as: please rehandshake, or foce a new SSL3 sessionid...).
 
I hope I'm saying this clearly. The summary is: that client certs handling has gone beyond the web app model, and now enables the web pipeline model (in IIS and windows land). And, its all available to the vb programmer (vs the specialist writing communication library code). If we assume that client certs failed because they didnt add enough value to the webapp model (specificatlly), now realize that their value has been made indepedent of that "webapp model". Thus, one can reconsider the value of the client cert, as its not longer LIMITED ... to that webapp model. I.e. Perhaps it was the webapp model all along that was the problem (causing client certs to fail). Perhaps it was never something about client cert and https themselves, only how they were bundled with the web1.0 world.
 
One very tangible benefit to the change described above occurs in IIS-hosted site  - since the "behaviour insertion" metamodel allows certs to be set free of the formally-mandatory PKI trust model, previous imposed upon any and all web apps using certs and IIS. Only PKI discovery and PKI chaining closure was allowed to influnece the pipeline itself. But, now, since one can install one's own security behaviour in the (IIS-enhanced) pipeline supporting a particular https endpoint for each particularly named resource within a site, each of those sets of behaviours can impose ...such as the webid validation model. This was not possible, until recently. You were limited to customizing the PKI model; period. Now, you get to define your own cert-handling model per se (and obviously customize it for the https semantics one desires, free of PKI). IIS is perfectly happy to host now n "cert semantic" models, on the n endpoints one defines - some of which ae doing PKI semantics, some are doing webid validation, some are doing certs trust models leveraging signed SAML metadata files, others are pulling keys from dsigned XRDs, or signed json blobs, and perhaps some are pinging xmpp channels or workin an ipv6 multicast group...with group-centric RSA key distribution models.
 
To my mind the core of webid is: "its a more evolved https". The various elements on the various orthgonal axis of DanB';s diagram are ALL extra, in my mental model. They are not core (being often n variations of the same thing, on each axis). The webid core is" that https is now free of PKI; client certs are now free to engage in different semantic worlds; that https can thus to deliver different "channels" with different secuirity semantics ; and all this communication (not data) semantics is DEFINED by the metadata about the certs.keys (which is of course the webid/foaf/sioc ontologies).