Re: WebID, WebID Protocol definitions and requirements.

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.

Kingsley
>
> Best,
>
> Nathan
>
>> Your definition is conflating implementation details with concept 
>> definition. A WebID is a verifiable URI. This kind of identifier can 
>> be verified using a variety of protocols. An example of such a 
>> protocol is the WebID authentication protocol.
>>
>> The WebID protocol uses RDF model based structured data and entity 
>> relationship semantics to determine that a WebID's referent is 
>> associated with a Public Key, and by implication its private key.
>>
>>
>
>
>


-- 

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