[foaf-protocols] Multiple URIs in SAN extension

Reto Bachmann-Gmür me at farewellutopia.com
Sat Aug 14 22:25:11 CEST 2010

----- Original message -----
> On 5 August 2010 18:55, Stéphane Corlosquet <scorlosquet at 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.

> > I believe the jabber folks were thinking about adding an entry for JID.
> email+webfinger seems to be gaining some traction, tho im not sure if
> that's yet able to store a public key, and you may not wish to disclose
> your email address.
> > 
> > thoughts? controversial opinions?
> > 
> > Steph.
> > 
> > _______________________________________________
> > foaf-protocols mailing list
> > foaf-protocols at lists.foaf-project.org
> > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100814/dcd465ee/attachment.htm 

More information about the foaf-protocols mailing list