WebID-ISSUE-1: Multiple URI entries in the SAN extension

WebID-ISSUE-1: Multiple URI entries in the SAN extension

http://www.w3.org/2005/Incubator/webid/track/issues/1

Raised by: Stéphane Corlosquet
On product: 

from https://github.com/webid-community/webid-spec/issues#issue/2

The WebID spec does not currently cover the case where there are more than one SAN URI entry in the same certificate. There was a thread [2] on this topic started by Bruno a while back but it only discussed the other types of entries (like email) without reaching any consensus on the multiple URI entries.

from http://lists.foaf-project.org/pipermail/foaf-protocols/2010-July/002711.html
[[[
Since there can be multiple entries (and some of us have created certs with more than one SAN entry), are they all expected to be dereference-able and contain the same public key? Should we impose a limit of one entry in the SAN extension?
]]]

and from http://lists.foaf-project.org/pipermail/foaf-protocols/2010-July/002775.html
[[[
> Should there be multiple entries of type URI in the S.A.N. extension?

Possibly. We need to think of what this implies in terms of semantics too.

I would suggest to allow multiple URI entries: "The Identification Certificate MAY contain multiple URI entries in the Subject Alternative Name extension. The Verification Agent MUST attempt
to verify at least one of these entries. It MAY verify more than one
entry. The Verification Agent MUST NOT consider an entry for which the
verification failed as authenticated, even if other entries have been
verified successfully."

Do we then want to treat multiple successfully verified entries as owl:sameAs, or should we leave that to the RDF?
]]]

Here is a use case for having multiple URI entries. In a typical WebID authentication workflow, if your WebID provider is down for some reason, then you cannot authenticate with your WebID (leaving aside the particular cases of caching and trusted data sources). If your certificate contained another WebID URI, the Verification Agent could then dereference this other WebID URI to attempt authentication (provided the same public key was published at the second WebID Profile Document as well). The problem though is to know what your WebID URI is once you've authenticated via an alternate WebID URI. Should the Verification Agent trust that you are WebID URI #1 when the authentication sequence via WebID URI #1 didn't work and only WebID URI #2 worked? Clearly no, unless you can prove that you also own WebID URI #1 by having logged in via this URI in the past (in which case the Verification Agent would merge the two identities). Is this a good use case to justify the use of multiple WebID URIs in the same certifiate? It would be equivalent to having to separate certificates, but the great advantage is that from user point of view you just have to choose one identity, however many WebID URIs you have associated with this identity (and you're pretty much sure at least one of your providers/servers will be up).

This raises a related issue. If we expect WebID to take off and to be easy to publish your own WebID, there ought to be ways to work around the fact that servers go down, that's one reason why there are so few OpenID providers and they are all big players providing decent QoS. In the case of WebID, even if you choose the best software implementation you can find on the market, you're still dependent on your hosting provider. WebID provisioning should work on cheap hosting to be truly decentralized avoid the same centralization OpenID has.

Do we have other scenario where it is useful to have multiple URIs? There might be cases where a URI entry of the SAN extension is not meant to be a WebID (think other protocols sticking a URI in a certificate like we do). This might be fine and play nicely with the above scenario as long as the Verification Agent tries the authentication sequence with each URI entry until it finds a matching public key in whatever document each URI dereferences to.

Steph.

[2] http://lists.foaf-project.org/pipermail/foaf-protocols/2010-July/002775.html

Received on Thursday, 27 January 2011 14:07:55 UTC