Re: WebID-ISSUE-23: Authorized Representations and Dereferencing a WebID URI [WebID Spec]

On 1 Feb 2011, at 12:04, WebID Incubator Group Issue Tracker wrote:

> WebID-ISSUE-23: Authorized Representations and Dereferencing a WebID URI [WebID Spec]
> Raised by: Nathan Rixham
> On product: WebID Spec
> A fundamental element of the WebID protocol, if not the purpose of the protocol, is to establish a URI which can be used as a name (identifier) for the Identifying Agent.
> The authorized use of a WebID URI by an Identifying Agent is deemed (by the conceptual protocol) to be established by proving ownership of a token, and then verifying the presence of that token in a representation received by dereferencing the WebID URI.
> The realization of this element is currently defined by the use of Public/Private Key pairs, the public key is used as a token, ownership of that token is confirmed by passing the public key in a certificate as part of the TLS authentication flow (where ownership of the corresponding private key is proven), when the WebID is dereferenced the presence of the public key in the representation is verified, and the authorized use of that WebID URI is established.

The token way of thinking is misleading. It is way too syntactic a way of thinking, coming from a pre-semantic school of thought. For example there is no need for the profile document to publish the public key in the same encoding (decimal, hexadecimal, binary) as the encoding that came in the X.509 certificate. What is happening is the construction of a proof. The Profile Document is a document that is definitional for the #terms it contains. It defined the WebID as the thing that knows the private key of a given public key. That is combined with a TLS proof between the client and the Relying party (the friend you want to login to) where the client prooves he has the private key.

See the FAQ

If you want a philosophical background to that see my presentation "Philosophy and the Social Web" 

> "WebID resource" is used in this case to refer to the agent which responds to dereferencing requests on the "WebID URI".

Not quite. The WebID refers to the agent that knows the private key of the public key published at the WebID profile.

> It is therefore vital that:
> - the dereferencing process be well defined

Yes. Is it badly defined? Please propose text for where you see issues.

> - the "origin server" which will respond to a dereference request is authorized to do so

You mean the document serving the profile? The profile server? 
Not sure why this is a requirement.

> - the authenticity of the "representation" received by the act of dereferencing can be established

You mean that the representation returned come from the correct server and not have been
modified. Yes, the stronger that is, the stronger the proof. One way of doing this is to have an https URI.

> - it can be proven that the representation has not been tampered with (signing) - or - cannot be tampered with (by removing the possibility of intermediaries).

Yes, that is what having a WebID with an https URI does. Signing profiles might do too, but involves more other issues.

> All of these points are not addressed by the current WebID protocol.

I am not sure they are not. But agree on the points.

There seem to be a number of issues tied together in this issue, which seem to be independent. 


Social Web Architect

Received on Tuesday, 1 February 2011 14:36:33 UTC