RE: Browser ID

I dont need to solve what this group is not about. It about taking TLS more or less as is, warts and all, and tweaking at most 1% of it so that the semantic web can then bring all its value to bear. I leave it to my colleages to prove that the semantic web does what it professes (since Im a skeptic, but one willing to be converted). You said classical PKI revocation is hard (and unadoptable). Classical PKI revocation is a URI in a cert that points to a list (the CRLDP URI) or to an agent endpoint (the OCSP URI). The CRLDP is a classical web document lookup, cacheable as normal. The OCSP URI is a glorified CGI endpoint which mints a signed blob given a signed request. Though the OCSP endpoint mints a signed ASN.1 blob - acting as a classical web service - it could be minting a signed JSON blob for all it matters. Who cares about presentation syntaxes? A WRAP endpoint is a modern equivalent of OCSP. It takes a signed request, and mints a signed response; delivered as a classical webservice. Typically, the input is a signed cert or signed SAML blob - including self-signed blobs. Typically, the output is a HMAC-signed SWT token; though tomorrow it can be a signed JSON object, serialized canonically somehow (in the 15th canonicalization effort...) The conditions for processing can be the same in WRAP as for OCSP : the request id is not on an implied list of revoked/invalid entities associated with the endpoint or some field in the request. If one hates ASN.1 with a vengance AND one hates XML with a vengegeance, perhaps one likes JSON as a presentation syntax. Thus we get signed JSON blobs, as bearers of good or bad news about someones tagging of another entity, named by URI. As the output token handling matures, it will evolve to have EXACTLY the same same fields as its ASN.1 and XML foreunners. This is becuase the fields are there to signal processing and handling requirements at layer 7, being indepedent of presentation syntax. A FOAF card with a list of tagged URIs in a relation is the modern equivalent of a CRL. We have signed FOAF Cards for years (with PGP, using PGP-wot). Alternatively (and arguably), the same foaf card at an SSL endpoint is authenticated by that endpoint - and said authentication pvrovides integrity of the list of tagged URIs - tagged as revoked/invalid, etc. Nothing unwebby or unadoptable about any of that! Myth busted. How does this differ from other proposals? Well, it keeps the user in control of their long term keys'; the keys being THEIR intellectual property. They cannot be "revoked" - an authority can only makae a revocation statement, then some may with to consider. It keeps a different party (of several) in charge of making issuing and revocation statements, distinguished from key management activities. It unbundles from the CA the combined duty of managing keys, issuing certified keys, revoking the authority associated with a valid certification.  NOw, we have political problems, little or nothing to do with revocation - but everything to do with URIs in inbound blobs - be they revocation pointers or FOAF card pointers.  As you argue, 10-20 year old data centers designs founded on classical CISCO/SUN design principles are largely permiter based. The inbound client cert doesnt penetrate to the app server, typically. Its embedded URIs never make it to the app server, thereore. Therefore websso posts of signed blogs works better than client certs and transport-centric https, as we all learned more than a decade ago.  So what do we do (in webid)? Even if we solved the delivery of the client cert to the app server, lets not forget what paypal said (probably as a front for a DoD program office): we will not resolve inbound references to JUST ANYWHERE. By implication, they will not resolve them at the perimiter firewall OR the app server (should patents on extending SSL to the app server be ignored). They will not make outgoing queriers to arbitary addresses, period. And, I dont blame them. NOw, I think the semweb has the solution to this, since is has mature triple store aggregation and caching principles up its sleeve. But, there are poltiical problems, as webid specficially doesnt rely on such aggregation principles. It has a de-referencing model, at its core. it WANTs the Relying Party app to be able to interact directy with the users foaf-agent (not just a foaf card, and its tiples). Its an important part of the study, so that things like semantic ping work - allowing for extended-webid properties to come into play - for BUILDING-OUT the UCI trust model represented by the triples.          > Date: Sat, 16 Jul 2011 16:43:18 -0700
> From: ben@adida.net
> To: home_pw@msn.com
> CC: kidehen@openlinksw.com; henry.story@bblfish.net; public-xg-webid@w3.org
> Subject: Re: Browser ID
> 
> On 7/16/11 3:44 PM, Peter wrote:
> > Lots of myths being restated (rsa is CPU bound, ssl is hard on
> > servers, crl caching is hard (whereas a trillion web page caches are
> > not).
> 
> I said none of those things.
> 
> The only item that resembles something I said is "ssl is hard on 
> servers." If you read the full message, you'll see that I'm talking 
> about having client-side certs carried through all the way to the 
> application layer code. It's hard because of the abstraction layers that 
> exist in many practical deployments. It's the same reason that Digest 
> Auth has been so tough for most applications to deploy.
> 
> Btw, if you have a revocation solution that solves the privacy problem 
> in a federated system *and* the failure condition model, I'd love to 
> hear about it.
> 
> -Ben
>