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

---------- Forwarded message ----------
From: Reto Bachmann-Gmür <me@farewellutopia.com>
Date: Sat, Aug 14, 2010 at 4:25 PM
Subject: Re: [foaf-protocols] Multiple URIs in SAN extension
To: Melvin Carvalho <melvincarvalho@gmail.com>, Stéphane Corlosquet <
scorlosquet@gmail.com>
Cc: foaf-protocols@lists.foaf-project.org


 ----- Original message -----
> On 5 August 2010 18:55, Stéphane Corlosquet <scorlosquet@gmail.com>
> wrote:
>
> > Hi,
> >
> > The WebID spec does not currently cover the case where there are more
> > than one SAN URI entry in the same certificate. Do we have scenario
> > where this would be useful?
> >
> > 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 certificate? 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).
> >
> > <side-note>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 the 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.</side-node>
the user must trust the WebID profile hoster and its security, promoting
distribution over many cheap services might disguese this fact.


> > 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.
It shouldn't stop there but check all key, as the authorization layer might
associate the rights to a verifiable identity other than the first one
found.

Cheers,
reto