Re: Question/idea: Self-contained WebID

On 05/28/2014 01:52 PM, Mo McRoberts wrote:
> I don’t know if it’s been covered, but if you sacrifice attribute exchange (or rely solely on attributes baked into the cert itself), you could do TLS-based “WebID” with a URI which is verifiable only using the public key in the cert.
>
> For example, it’d be ugly (though who cares if your WebID URI is ugly if you never have to see/type it?), but you could do it with a URN containing your key algorithm and pubkey hash (e.g., urn:rsakey:<fingerprint>) — as an informal URN scheme it’d only take a couple of weeks to bring into life if somebody was really keen.
>
> Server-side applications could even use that as a default URI for an agent as a matter of course, adding a resolveable URI as a preferred alias if one’s available.
>
> M.
>
This sounds very interesting.  Using a scheme like this, if something
happens to the user's WebID Profile URL, could the user simply move the
WebID Profile to another server/URL, update their client-side X.509
certificate with the new URL, and then the next login to a site that
uses that WebID would succeed by using the hash, then extract the new
URL from the cert and fetch the WebID Profile from the new location?  Is
it possible to update the URL in the cert without requiring the issuing
of a new cert all together (as long as the cert isn't signed by some CA
but simply self-signed and resigned after changing the URL)? It seems
this would require sites to store two pieces of information, the cert
public key hash, used for logging in even in cases where the WebID
Profile is unavailable, and the URL of the WebID Profile with the extra
attributes that can be used/linked for social networking purposes even
when the user is not logged in, if it is available.