- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 15 Nov 2012 13:01:08 -0500
- To: Henry Story <henry.story@bblfish.net>
- CC: public-xg-webid@w3.org, "public-webid@w3.org" <public-webid@w3.org>
- Message-ID: <50A52DE4.2040204@openlinksw.com>
On 11/15/12 12:28 PM, Henry Story wrote: > 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. I am not really implying that. But for whatever reasons that's what you discern from my preference for URI. You want to push an Address/Locator as a Name. It does work, but it ultimately hits a problem with intuition and flexibility. You are also opting for *implicit* Name/Address indirection as opposed to catering for *implicit* or *explicit* Name/Address indirection. A Linked Data URI exploits indirection such that it denotes an entity (anything) while also identifying a Web resource. The owner of a URI is the one responsible for indirection handling choices. There's no one size fits all solution to this matter, hence the utility of the abstraction. > 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 disagree. > 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. Why extend when you already have abstraction on your side? All you need to do is add more examples in the future when there's a need to tap into the breadth of the abstraction as circumstances demand. If we produce conceptual guides for WebID and its authentication protocol, these matters will simply vanish. If we start the game from step #2 we'll always be an interaction away from revisiting this issue. Remember, I said, I'll reluctantly live with the use of URL in the WebID definition, even though I also know it won't end the matter. > > 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. And how does s/URL/URI/g stop that? > > 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. You need a conceptual overview. No technology gets adopted without some conceptual overview accompanying the technical specs. This is the fundamental issue here. > > As for representation I am still for Turtle and RDFa being together things that > verifiers MUST understand. I don't have a problem with Turtle. It just doesn't need to be in the definition of what a WebID is. > 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. We need a conceptual guide. This has to accompany the technical specs and implementation examples. Kingsley > >> -- >> >> 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/ > -- 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 15 November 2012 18:01:31 UTC