Re: WebID 1.0 -- Section 3 -- Removal of Note

On 2/17/13 8:23 AM, Henry Story wrote:
> On 17 Feb 2013, at 13:59, Melvin Carvalho < 
> <>> wrote:
>> "Note
>> Hash URIs are encouraged when choosing a WebID since 303 redirects 
>> require an extra HTTP request for an Agent to get from the WebID 
>> <> 
>> to the WebID Profile 
>> <>. 
>> All examples in the spec will use such hash URIs."
>> This has come up in some other threads.
>> Leaving the # vs slash "perma debate" aside may I propose that this 
>> part is removed.
> This is issue-74
>> While, I am in favour of the sentiment of using # URIs but I dont see 
>> any evidence that this note will have the desired effect.  Why even 
>> mention 303s at all? All the examples use # URIs so, imho, this point 
>> is not really needed, and may add confusion to implementers.
> We are mentioning 303s because we need to mention the relation between 
> the WebID and the Profile document.

No true. You are doing so because you are trying to impose a personal 
preference. Here is a very simple solution re. docs:

1. WebID Spec -- describes what a WebID is, no more no less
2. WebID oriented Profile Document guide -- describes the minimal 
requirements for a document that would play a key role in verifying the 
identity of its subject
3. WebID+TLS Protocol -- a document that describes how the combination 
of a WebID and a Profile Document deliver Web-scale verifiable identity.

You can actually complete 1-3 without ever mandating a style of HTTP URI 
and here's why, since for whatever reasons, this remains unclear to you:

Human (he/she) making a profile document using the file create, save, 
and share pattern:

In this scenario he/she needs to produce a simple profile document that 
enables them ultimately serves as their own identity provider. The 
easiest way forward would be to look at examples from 1-3 which are all 
hash URI based.  Net effect, to get going with next to zero gravity, 
they create a document and publish to a Web accessible location [1][2][3].

Software agent making a profile document:

In this scenario the Agent needs to produce a profile document on behalf 
of itself or others e.g., allowing a user with Twitter, Facebook, 
LinkedIn etc. accounts to leverage these services as Identity Providers. 
The developer of such a solution will simply use whatever HTTP URI style 
works best for the solution being delivered. The only proviso is 
conformance with the requirements for publishing 5-Star Linked Data [4].

> We need to tie these together, since otherwise there is nothing to say 
> about WebIDs.

All you have to say about a WebID in the WebID description document is 
A WebID is a HTTP URI that denotes an Agent.

You can embellish the above with what's there right now modulo the 
distracting notice.

> There are two ways WebIDs get related to the profile document: either 
> the hash to non hash relation, or the 303s link. Speaking of 303s is 
> just a consequence of allowing them  into our scope per definition.

See my points 1-3 above. You really need to stop conflating a WebID and 
a WebID oriented Profile Document.

Links (none of this is new to you, Henry):

1. -- How To Create & Control Your Own Verifiable 
Digital Identity, at Web-scale
2. -- ditto using Dropbox (one of an increasing 
number of Web services oriented towards the: file create, save, and 
share pattern)
3. -- ditto using Amazon S3
4. -- using Twitter, LinkedIn, Facebook, G+ etc.. 
as Identity Providers (the kind of compatibility solution that brings 
the Web 2.0 installed base to WebID with ease via power of Linked Data).

> Henry
> Social Web Architect



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web:
Personal Weblog:
Twitter/ handle: @kidehen
Google+ Profile:
LinkedIn Profile:

Received on Sunday, 17 February 2013 18:04:11 UTC