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

---------- Forwarded message ----------
From: Reto Bachmann-Gmür <me@farewellutopia.com>
Date: Tue, Aug 10, 2010 at 3:20 AM
Subject: Re: [foaf-protocols] Multiple URIs in SAN extension
To: Stéphane Corlosquet <scorlosquet@gmail.com>,
foaf-protocols@lists.foaf-project.org


 ----- Original message -----
> Hi,
>
> Reto committed a change [1] suggesting a simple fix for the multiple SAN
> URI entries issue which is to require exactly one URI entry, not sure if
> he meant to postpone that issue to keep the spec simple for now or close
> it entirely (there is still the same issue in 3.1 as well). 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.
>
>
> - 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 [2]
>
> > - 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?

I missed this mail ans missread the next one. I can very well live with the
proposal above too. As for identity I don't think the verified claimed
webids should be threated as owl sameAs. But rather as potentially different
identities the holder of the key pair may legitimately represent. I'm
thinking at a collective profile cotaining public keys of its members that
may subsequently act with both there individual as well as with the rights
of that collective.

Cheers,
reto