WebID definition - take 2

Kingsley and Jürgen were quite strongly -1 on the TPAC definition, and Kingsley even made this known on the IRC at the time ( one hour after the discussion, since he was not present ). I just spent some time with them to see where he would agree as the arguments on the list were very long http://lists.w3.org/Archives/Public/public-webid/2012Nov/0000.html

I. Agreement: 
-------------

We agreed on the following two points:

(1) A WebID is "A URL that denotes an Agent - Person, Software or Organisation."

   I think we probably have 100% agreement on this everywhere.
   Note that we use _U_R_L_  here as this makes it clear that the Identifier is dereferenceable.

   ( Also the idea was that this is easier than defining an HTTP URL, since one would then be left over with HTTP or HTTPS or ... ) The URL concept captures the most important part of the Web which is that you there is a canonical way of dereferencing the URL and getting the document that it names. It should be possible then for the LDP folks to define the HTTP subset of WebIDs as being the ones they are interested in. 

   Also I would like to use Tor's .onion and i2p's .garlic  urls in order to be able to make a strong case for the value of having social networks in those anonymised systems. This is really important in the security space. ( it turns out that those are also http urls - but that's a bit of a hack that they are ! )

(2) "The WebID when dereferenced MUST return a document/representation that describes the URL referent uniquely."

  This makes it possible to use different forms of authentication given different identifying descriptions:

  a) Using openid: { <#me> foaf:openid <> } 
  b) Using email:  { <#me> foaf:mbox <mailto:joe@name.com> }
  c) using a postal mail: { <#i> :office [ 
                                     :street "32 Vassar Street";
                                     :street2 "MIT CSAIL Room 32-G524";
                                     :city "Cambridge";
                                     :postalCode "02139";
                                     :country "USA"
                                    ]
                            }
  d) using a telephone: { <#i> :office [  :phone <tel:+1-617-253-5702> ] . }
  e) using a public key { <#i> cert:key .... }

As I understand the main reason we shifted from the current definition which was restricting WebIDs to public keys, was to be able to allow wider range of definitions and so a wider number of authentication protocols to be associated with a WebID.

  Notice that all these graphs describe the user with some inverse functional property or owl key, which is what makes these "uniquely identifying" description, or what is known in philosophy/logic as Definite Descriptions. 

 The public key of course has a lot of privacy advantages over the others options... but that is what will be described by the WebID Authentication Protocol over TLS.
   
So with (2) we still have an identifier that does not require backchannels to give the sense of the referent: ie: something that can be used to uniquely describe him. These are URLs so they are also linkable in a meaningful way so the Linked Data folks will be happy - as they should be. 


II. Disagreement
-----------------

I think the disagreements were:

1) limiting to only http URLs or https URLs

 I think it is difficult also to make limitations like this. There is no reason why sub protocols cannot make 
restrictions there - like LDP. At the same time I think that a WebID has to be a URL. It has to be able to find a 
document that can be dereferenced - otherwise there is really nothing much one can do with this. 


2)  Turtle as default representation

Tim Berners Lee and Alex Bertails was clearly strongly in favour of Turtle being the default representation that must be returned when requested, in order to foster interoperability.  A lot of people agreed with that argument. 

Until now the WebID spec has tried to be open, since the advantages of having rdfa returned are clear to many, and also since we could make a lot of other formats GRDDLable. The idea there was to allow as many people to publish WebIds as is possible and not get into religous wars over syntax with them. This pushed the burden of interpretation to the verifying agent.

  The question then is where should the interpretation burden be: on the WebID writer, or on the verifier?

3) #urls

  I think there are good reasons for the WebID to be restricted to  #urls, especially as this would remove all the problems we have with HTTP redirects and the question as to what that would mean for the strength of authentication, and there is no need to look into the whole http-range-14 issue. This also makes it easy to explain WebID by reference to the URI/L spec?


III. Conclusion
---------------

I think it is ok to add II.2 and II.3 restrictions above if it helps make adoption easier.

The best way we can tell in fact is to see how current implementation agree or disagree in that
space. I think writing a WebID over TLS validator will probably help there.




Social Web Architect
http://bblfish.net/