Re: What is a WebID?

Kingsley Idehen wrote:
> On 11/4/12 1:18 PM, Melvin Carvalho wrote:
>> Our solutions are interoperable.  Universal does not mean unique!
> 
> Wrong again.
> 
> The solutions in question (re. WebID) are no longer interoperable. A 
> verifier will fault on a hashless URI. It will fault if a profile 
> document isn't comprised of Turtle content. It will also fault on a non 
> http: scheme URI.  You seriously regard that as interoperable?

This is interesting.

I viewed the constraints as setting a minimum bar for interoperability.

Let's say HTTP + Turtle + Hash URI was level 1.0 support.

Then add in RDF/XML, RDFa, NTriples. JSON-LD to get level 1.8, add in 
acct: or ftp: to get level 2.2, and so forth.

Each serialization and protocol added to the mix increases the power of 
WebID-protocol, this is a good thing, not to be precluded in any way.

The Hash-URI thing is a different issue, there are multiple reasons they 
have preference, but it's probably worth me mentioning why I am +1 to 
having hash-http-URIs as the "default" for level 1: It's because I see 
WebID as tying a URI to both parts of a key pair, the TLS side binds the 
URI to the private part, the act of dereferencing ties it the URI to the 
public part, and the public part is already tied to the private part. If 
a slash URI <a> redirects to another document <b>, then it's <b> that is 
tied to the public part, not <a> that's in the cert. This to me, opens a 
lot of questions, and feels like it opens the door to exploits, mitm 
attacks, and doesn't "prove" uri ownership/control. Hence why I have a 
strong a want for #hash URIs here. If there's no problem with the 
redirects and the proofs all work out / it's all good, then I'm happy 
with either (personal preference will always be hash's of course).

Make sense?

Received on Monday, 5 November 2012 23:36:23 UTC