RE: The 3 stack layers of BrowserID and WebID

webid is only tied to client certs on account of a "adoption goal" - its there. Ive argued (and deployed) the guts of webid when the URI is delivered in a SAML posted assertion to an RP. Since Im a developer, I even built my own SSL client, replacing the X.509 format cert in the cert msg with my own (signed JSON) blob. SSL doesnt care... though obviously deployed https servers do (since few know how to parse my custom cert token in the SSL msg). The debate is not about client certs, therefore. Its about how https is applied. IN webid, the URI is what matters, so it use (in identity mode) FITS with all the logical assumptions of the semantic web. Remember, webid exists to project the semantic web, and the linked data movement. Its design aimed to stay consistent with the axioms of the semantic web. Webid is more than merely looking up a foaf card on the fly, given a URI handle. Now, webid is advanced, compared to browserid (which is a yaap - yet another assertion protocol). The question is, since both movements are competing for browser influence, is: should the infrastrcuture attempt to reach out to the semantic web'goals or not. If not, one does yaap.  Traditionally, the number of folks who care about semantic web and/or its AXIOMS are few in number. But those that do care, seem to be able to articulate a next generation web. unfortumatenly, most devleopers could not care less about the next generation web to be had 2 years hence, let alone 5- 10 years. If browserID had any strategic elements in its thought train, it would enable SOME of the webid wider mission, allowigs its assertions to cmmunicate the webid URI, so that the guts of webid processing can take place (with or without the https tie ins) - enabling thereby SOME future advaned capabilites to find their place in the web as-is.Date: Tue, 19 Jul 2011 20:22:45 +0100
From: kidehen@openlinksw.com
To: public-xg-webid@w3.org
CC: dev-identity@lists.mozilla.org; ben@adida.net
Subject: Re: The 3 stack layers of BrowserID and WebID



  


    
  
  
    On 7/19/11 1:48 PM, Henry Story wrote:
    

    On 19 Jul 2011,
      at 04:56, Ben Adida wrote:
      

      

      
        
          We have
            different requirements.
            

          
          Not sure we do.
          

        
        At the very least we have different sub-requirements. You want
        to
        

        leverage TLS client-side certs. We specifically don't.
        

      
      Good so this is a big misunderstanding - and a very understandable
      one of course. WebID leverages TLS and X509 certificates because
      that is  what is available in all current browsers and because it
      works, not  because we love TLS or X509.  Mozilla labs can change
      the technologies in one browser, so you can of course change what
      is available and so change what WebId needs to run.
      

      

      I think it is important to distinguish the different layers of
      technology  that are being used by the current BrowserId and the
      current WebID, as I argued on stackexchange article comparing
      WebID and BrowserID http://bit.ly/na7vsA
      

      

      a. Transport:             TLS            vs      unencrypted
      tcp/ip
      

      b. Cert formats:         X509            vs        signed JSON
      

      c. Auth method: Subject PK verification  vs    Issuer PK
      verification
      

      

       From the above table we can see that WebID/foaf+ssl is described
      by the first column of the table (X509, Subject PK verification)
      whereas BrowserId is described by the second column of the table
      (Signed JSON, Issuer PK verification).
      

      

      So that is where we are now. From that perspective it looks like
      both protocols are like oil and vinegar: they can't mix -- even
      though they are destined to always be mixed, and then be used to
      make a good tasting salad. ;-)
      

    
    

    Mixing depends on details of the email verification protocol.
    Basically, how they associate public keys and email addresses
    (maito: URIs).
    

    

    So consider
      each layer:
      

      

      a. Transport: Does WebID really require TLS (other than for
      securing the transport)? Not really, what is required is that the
      browser sign a token with the users private key and for that be
      the basis of the verification of his identity.
      

      

      b. Cert formats:  WebId is designed at the semantic layer, not the
      syntactic one. So we don't really care if a new certificate format
      comes along. The same logic applies. So WebID can work very well
      with signed JSON certificates too.
      

      

      c. Auth method: WebID was going to look at some point at issuer
      certification verification. Now you have presented a good use case
      - with the proof that you cared enough to implement something, not
      just waffle about how useful it could be - we have something to
      work on.
      

      

      The point is that each element of the stack is orthogonal. Each
      auth method can be used with either transport layer and with each
      certification format. Furthermore the authentication methods can
      be combined!
      

    
    

    Yes, and this will happen (more than likely) if the email
    authentication protocol is clear about the relation that connects a
    mailto: scheme URI to a public key, ultimately this is the key to
    the matter. Even if they opt not to use or recommend Webfinger.
    

    

    

    So why am I
      really excited about the combination of layers currently called
      BrowserId that you have developed? Well because first you Mozilla
      *can* change those layers, and
      secondly you have shown that adoption is then very quick: if
      services don't need to add TLS they can add distributed identity
      in an instant. They are less secure than if they did, but one must
      fight one micro battle at a time. [ So I am assuming here that
      there are no blocking security issues in what you have built ].
      

      

      Once this is seen, then I think you will understand that allowing
      us to explore the WebID auth method as part of your experiment,
      will not tie you into X509 or TLS. With a bit of thinking we
      should even be able to work things out so that there is a base
      protocol that works along the lines of what you have call it  -
      BrowserId 1 - and then a way to enable extensions that would take
      advantage of WebID authentication - WebId without TLS or X509 let
      me be very clear!
      

    
    

    Yep too, but we'll see when the details re. mailto scheme and public
    key association are clear :-)
    

    

    

    -- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen