W3C home > Mailing lists > Public > public-xg-webid@w3.org > February 2011

Re: WebID-ISSUE-21: Temporally Weak URI Ownership [WebID Spec]

From: Henry Story <henry.story@bblfish.net>
Date: Tue, 1 Feb 2011 17:31:59 +0100
Message-Id: <2E8C7DCB-8CC2-4B82-AEE2-A8193D9BB6F9@bblfish.net>
To: WebID Incubator Group WG <public-xg-webid@w3.org>

On 1 Feb 2011, at 11:45, WebID Incubator Group Issue Tracker wrote:

> WebID-ISSUE-21: Temporally Weak URI Ownership [WebID Spec]
> http://www.w3.org/2005/Incubator/webid/track/issues/21
> 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 token way of thinking is misleading: it is way too syntactic, coming from a pre-semantic school of thought.
See the FAQ

> 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.

yes, but not because of the presence of a token. It is because of the presence of
a statement, understood non syntactically, and because this combines with a proof
of knowledge of private key made earlier.

> The use of Public Keys in this manner proves to be temporally weak, in that it only establishes that the key pair holder /had/ write access to the WebID resource at some point in the past, the key pair may since have been stolen, or the machine running the identifying agent may have been compromised.

This type of issue exists in all protocols I think. The most serious way to deal with this
is to have token cards associated with a public key. (And if you are really serious force that public key to work with biometric verification) It is obvious then when one looses one's token card. One should then just have another access method to one's profile page to disable the token card by removing the certificate.


An interesting issue that might be worth opening is if there is a way in the protocol
to tell that a public key is protected by such a hardware token. That could give extra
confidence to authenticators of a public key. My guess is that this would require a description of the public key as of type HardwareKey or some such thing.... Should I open an issue on this?

> WebID protocol as it stands, does not make any provision for establishing that an identifying agent still has write access to the WebID resource.

yes, it is the responsibility of the Identified agent to change that resource in case 
of doubt over his unique possession of the private key. 

By the way this explains why we talk of write access of the profile document. Logically there is no need for a write access relation. Neither in fact does the identified agent need to have direct write access. But the description in the profile needs to correspond to the state of knowledge of the identified agent (does he uniquely "know" the private key), which is usually his responsibility to keep track of. 

> Such provision could be made by swapping, or augmenting, the use of key pairs, with one time tokens - or by some other method.

And then you would still have the issue with the keys required to build the one time tokens, no?  I  think you have just moved the problem one step further out.

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

I have been calling it the Profile Page. 

Social Web Architect
Received on Tuesday, 1 February 2011 16:32:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:41 UTC