Re: WebID, WebID Protocol definitions and requirements.

On 10/31/12 12:39 PM, Nathan wrote:
> Kingsley Idehen wrote:
>> On 10/31/12 12:10 PM, Nathan wrote:
>>> Kingsley Idehen wrote:
>>>> On 10/31/12 10:46 AM, Nathan wrote:
>>>>> All,
>>>>>
>>>>> I'd propose the following
>>>>>
>>>>> Definitions:
>>>>>
>>>>> WebID
>>>>> An HTTP URI with a #fragment which denotes an agent, when 
>>>>> dereferenced a description of the denoted agent is provided in 
>>>>> Turtle.
>>>>>
>>>>> Authenticated-WebID
>>>>> A WebID which has been authenticated using WebID-Protocol
>>>>>
>>>>>
>>>>> WebID Protocol Requirements:
>>>>>
>>>>> subjectAltName ... MUST be an HTTP URI and SHOULD contain a 
>>>>> #fragment ...
>>>>>
>>>>> WebID profiles ... MUST be in Turtle, and MAY be made available in 
>>>>> other machine readable formats such as ...
>>>>>
>>>>> WebID Verification Agents ... MUST support Turtle ... SHOULD 
>>>>> support other machine readable formats.
>>>>>
>>>>> Kingsley: I believe this would encourage best practise and push 
>>>>> people towards #frags and turtle for interoperability, but also 
>>>>> allow your and everyone's tooling to be conforming even when 
>>>>> supporting ProxyURIs and the like.
>>>>
>>>> No, because it invalidates all our work, in a nutshell. You are 
>>>> basically pushing a definition that ensures our hash-less proxy 
>>>> URIs will be marginalized by newer WebID verifiers. That definition 
>>>> tosses the WebID work we've done -- based on the AWWW and Linked 
>>>> Data principles -- in the bin, in a nutshell.
>>>>
>>>> You are pushing a new definition that rewards an early adopter 
>>>> (OpenLink) by invalidating its work. Again, we haven't implemented 
>>>> anything outside the realms of AWWW or Linked Data principles, and 
>>>> the end result is marginalization.
>>>
>>> This certainly isn't the intention.
>>>
>>> Striving to find a way of wording these constraints to make adoption 
>>> and interoperability simple, whilst rewarding people like yourself 
>>> and OpenLink who have went over and above to do WebID+++.
>>>
>>> Not to preclude or marginalize anything, but to promote and 
>>> standardize a common simple set of the available options, and have 
>>> everything else as enhancements / extensions / integration which 
>>> broaden the scope to be web wide.
>>>
>>> To clarify for the remainder of this convo, can you confirm which of 
>>> these statements you would support / reject:
>>>
>>> subjectAltName ... MUST be an HTTP URI and SHOULD contain a 
>>> #fragment ..
>> -1
>>
>> The kills off the work we've done re. hooking LinkedIn, Twitter, 
>> Facebook, G+, WordPress, etc.. into WebID realm.
>>>
>>> WebID profiles ... MUST be in Turtle, and MAY be made available in 
>>> other machine readable formats such as ...
>> 0
>>
>> It doesn't break our proxy URIs since we have full support for 
>> content negotiation including QoS algorithms on the document 
>> publication side.
>>
>>>
>>> WebID Verification Agents ... MUST support Turtle ... SHOULD support
>>> other machine readable formats.
>> 0
>>
>> Our verifiers also leverage content negotiation and our sponger 
>> transformation services, so it doesn't matter.
>>
>> Question:
>>
>> Doesn't the current definition imply that WebID-authentication 
>> protocol based verifiers are going to be looking for hash URIs in 
>> Certificate SANs as part of their implementation? I believe the 
>> answer to that question is yes, and the end-result being that lexical 
>> space parsing will lead to faults when hashless URIs are encountered 
>> in X.509 cert. SAN slots. Again, that kills off our proxy URIs.
>
> Okay. Let's ignore the turtle side of things for now, all the 
> arguments on having a single common format supported by all are fairly 
> sound for interoperability reasons.

Turtle as a recommended document content format is fine. Of course, I 
would prefer SHOULD over MUST even though its my personal favorite.

>
> So the issue comes down to #frag - this is familiar.

Yes.

>
> Personally, I want to see as many people as possible using frag http 
> uris to denote agents, and also want to ensure that WebID protocol 
> encourages this, but does not prevent or preclude any dereferencable 
> http URI, frag or slash.

Yes, horses for courses compliance is vital here. "Deceptively Simple" 
vs "Simply Simple".

>
> For reference, would you be 0/1 with:
>
> a) definition WebID: an HTTP URI which denotes an Agent. Where you can 
> GET an RDF model as TURTLE.

0.

I don't believe you GET an RDF model. I believe you GET RDF model based 
document content.
>
> b) subjectAltName ... MUST be an HTTP URI ...

0.

The above doesn't break what exists. Thus, my 0.

It isn't a +1 because it closes the door to non http: scheme based 
de-referencable URIs. In doing so, the door will be closed to others 
working in the social web realm that will never use http: scheme URIs to 
denote Agents. Simple example, acct: scheme URIs where implementers are 
happy to use Webfinger to make said URIs de-referencable.


I believe there's a sizable Webfinger community out there to which the 
door is being closed, unduly.

Kingsley
> Best,
>
> Nathan
>
>
>


-- 

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