Re: telconf 07-11-2012 : what is webid

On 15 Nov 2012, at 17:39, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> On 11/15/12 10:34 AM, Henry Story wrote:
>> 
>>> On the other hand, URIs always designate a method to access the resource and designate the specific resource to be accessed (i.e. http://example.com/card#me). I think we should proceed to using URIs instead of URLs, especially since we're going to push WebID adoption over the HTTP scheme (afaik from TPAC).
>> 
>> I think it is clear that the only thing WebID Auth makes sense is for the WebID to be a URL. Ie it really does not make much sense with URNs which have no clear way of being dereferenced.
>> 
>> On the other hand URLs are still too general. mailto urls are still part of the URL spec. I think there is no need for us to be so general as to have all URL types because we can tie all the other authentication schemes together using Identity Interoperability
>> 
>> http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability
>> 
>> Restricting ourselves to http, https URLs does make for a clearer spec, without
>> creating interoperability issues. I can see that ftp and ftps would also work, but
>> we would certainly have a more testable system if we limited ourselves at first.
>> 
>> I think .onion and .galic urls can be deal with as proxy routing schemes.
> 
> You are making a poor case for compromising URI abstraction. It's a poor case.
> 
> URIs are the alpha and omega of the AWWW. End of story, everything else is a broken compromise.

Every URL ( the subset of URIs that interests us ) comes with a protocol. We use this information
for finding information about the URI. The schemes listed by the rfc1738 are 
   
http://tools.ietf.org/html/rfc1738#section-5

url            = httpurl | ftpurl | newsurl |
                 nntpurl | telneturl | gopherurl |
                 waisurl | mailtourl | fileurl |
                 prosperourl | otherurl

There are of course many more. If you look at the other identity mechanisms they
all tend to work on one type of url, with a specific type of referent. At a very
abstract level they all work in a similar way, as I think I showed in Identity
Interoperability

 http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability

But that does not mean that we have to make WebID be the abstraction that covers
them all. That would feel to them like we were trying to take over their space - 
and people in this space are very defensive of this. I think it is easier if we
make WebID something that is pretty harmless - an http(s) URL - then we show how we
can all work together. Later we can extend WebID to mean more. 

 This does 2 things for what then needs to be called "WebID Auth over TLS"

  1. It makes our spec easier to write
  2. we can test it more easily

 This also leaves it open to do "WebID Auth over BrowserID" later when the BrowserId 
folks get over their fixation on e-mail identifiers.

 Finally you don't really loose anything because we can and should also develop the 
Identity Interoperability wiki/note/spec to show how one can link them all together. 
As you can  imagine that is going to be a huge job, that will never stop. So we can 
have some spec for WebID and keep progressing on other fronts.

  As for representation I am still for Turtle and RDFa being together things that 
verifiers MUST understand. Note in the WebID over TLS spec we are not saying what
must be published, but what  verifiers MUST understand. So that is different from 
what LDP is doing. 

  In my view this is just a limitation we can put on the current spec. With careful 
wording its not far from what we currently have.

> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen	
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> 
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/