WebID Definition/hash2

From WebID Wiki

Historical Note: This page has been derived from a precursor hash page, which had set up a space for putting up negative and positive arguments for each option. This page removes the negative arguments sections, and transferred those into positive arguments for a particular case. It also removed arguments that did not have any supporters. For full context, it may be best to review both.

WebID Definition

Given that WebID's must refer to Agents, and that they must have an associated profile document, (that returns a default representation) the question here is which of the following restrictions one should have for WebIDs.

A URI is defined by RFC3986 and is constructed as follows: 

         foo://example.com:8042/over/there?name=ferret#nose
         \_/   \______________/\_________/ \_________/ \__/
          |           |            |            |        |
       scheme     authority       path        query   fragment
1. a WebID MUST be a an http(s) hash uri
that is scheme MUST be http or https and it must have a fragment identifier
2. a WebID MUST be an http(s) URI and SHOULD be an http(s) hash uri
that is scheme MUST be http or https and it SHOULD have a fragment identifier
3. a WebID MUST be an http(s) uri
that is scheme MUST be http or https

This is in the context of the current WebID definition editors draft.

Reasons: "A WebID ..."

1. MUST be an HTTP(S) hash (#) URI

The spec would say:

A WebID is a URI with an `http` or `https` scheme, which MUST contain a URI fragment identifier and which uniquely denotes an Agent (Person, Organization, Group, Device, etc.). The URI without the fragment identifier denotes the WebID Profile page.

  • Note: this is a definition of what the class of WebIDs are. It is not imposing a restriction on all URIs to say that only WebIDs can refer to Agents of course.
  • Hash URIs make it easy to explain the difference between the Profile document ( a Information Resource from WebArch ) where the description of the agent resides and the user identifier as in the picture in the spec (With 303's the job is more difficult, as one has to teach HTTP redirect codes which are not obvious to most users )
  • Necessary relation between URI and definition: The document defines the meaning of the WebID. Definitions are known as analytic truths - they are necessarily true. This is why publishing a public key in that document has completely different significance than publishing it elsewhere. This property follows directly from the URI spec:

    The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations.

    WebID Auth relies on the strength of the relation that exists between a WebID and its Profile document, to build up the security reasoning.
  • Cachability problem of URI redirections. HTTP1.1 states:

    The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable

    As a consequence ( but see the argument on HTTPBis improvements )
    • It is not specified for how long the redirection from the URI to the Profile page is valid for. When does the client need to check for it again?
    • There is an efficiency problem for all applications, but especially for those built in existing apps such as Web Browsers ( such as the JavaScript Tabulator ) since they must rely on that stack.


Other

  • Non #URI are problematic for LDP. What would it mean to:
    • to PATCH such a resource?
    • to DELETE it?
    • how would one create such a resource in an LDP Collection?

But this is something that is evolving, so it is difficult to come to a conclusion on now.

2. MUST be an HTTP(S) URI and SHOULD be an HTTP(s) hash (#) URI

This proposal acknowledges the existence of technical solutions for dealing with 303 redirects, but comes to the conclusion that 303 tends to complicate things for deployment, for consumption and for protocols such as LDP. It recommends therefore the hash URI solution as the cleanest way forward.

WebID definition spec with proposed changes.

The definition is:

A WebID is a URI with an `http` or `https` scheme which uniquely denotes an Agent (Person, Organization, Group, Device, etc.). This URI SHOULD include a fragment identifier. For WebIDs with fragment identifiers the URI without the fragment denotes the Profile Document. For WebIDs without fragment identifiers an HTTP request on the WebID MUST return a 303 with a Location header URI denoting the Profile Document.


Note that SHOULD is defined as meaning, quoting from RFC2119

SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.


Arguments in favor:

  • It promotes all the goodness of the MUST proposal above, but without excluding existing entity urls described in proposal 3 below.
  • It can help simplify the spec, as we don't need to have examples for 303s as well as hash uris
  • It fosters interoperability for

3. MUST be an HTTP(S) URI

A WebID is a URI with an `http` or `https` scheme which uniquely denotes an Agent (Person, Organization, Group, Device, etc.). For WebIDs with fragment identifiers the URI without the fragment denotes the Profile Document. For WebIDs without fragment identifiers an HTTP request on the WebID MUST return a 303 with a Location header URI denoting the Profile Document.

WebID definition spec with proposed changes (diff).

Retrieved from "https://www.w3.org/2005/Incubator/webid/wiki/index.php?title=WebID_Definition/hash2&oldid=598"