- From: Nathan <nathan@webr3.org>
- Date: Wed, 31 Oct 2012 16:39:19 +0000
- To: Kingsley Idehen <kidehen@openlinksw.com>
- CC: public-rww@w3.org
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. So the issue comes down to #frag - this is familiar. 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. 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. b) subjectAltName ... MUST be an HTTP URI ... Best, Nathan
Received on Wednesday, 31 October 2012 16:40:34 UTC