[foaf-protocols] Fwd: XAuth critiques
Bruno Harbulot
Bruno.Harbulot at manchester.ac.uk
Thu Jun 10 18:16:36 CEST 2010
On 10/06/10 16:40, Story Henry wrote:
>
> On 10 Jun 2010, at 15:40, Bruno Harbulot wrote:
>
>> In that context, you don't really have to prefer KEYGEN over p12. I
>> think what matters is to explain that a p12 file contains the private
>> key and shouldn't be distributed publicly. I reckon explaining all that
>> to non-technical users is one of the major problems for the usability of
>> FOAF+SSL.
>
> It is a major problem, but I think one has to keep it in perspective.
>
> First people do not need to back up these certificates. So a good
> Web ID provider would make sure to let the user know that he should
> ignore browser warnings about this.
Well, they don't need to back up the certificates only if they use it in
such a way you can re-generate your certificate on the fly. This is
indeed probably the majority of the use-cases at first, but that's also
the use-case with a low level of assurance.
There are two usages that come to mind where you'll want to make sure
you back up your private key:
1. People encrypt data for you using your public key (or certificate).
2. Systems with higher levels of assurance, where some information
regarding your identity has been verified out of bands, and where
systems have kept a trusted cached copy of this information. Then, they
would want to keep the association between the public key, the Web ID
and whatever data you've been able to assert and verify at that point.
(In this case, verification by de-referencing becomes irrelevant too,
the verification would be made against a trusted cache.)
This goes hand in hand with the notion of signing FOAF document (or
sub-graphs).
> Thirdly we should keep in perspective how much better the system is to
> the current user/password generation process, which pretty much is the cause
> of a massive number of security holes everywhere. Since people won't need
> to back these certs up, and since it is difficult to do anyway, we should be
> drastically cutting down the number of security holes in existence.
Point 2 above (higher levels of assurance) may seem a far goal at this
stage of FOAF+SSL, but from the security point of view, that's where the
added value is. Otherwise, there is little to gain (w.r.t. security)
from a Web ID cert that you can regenerate on demand compared with a
3rd-party log-on mechanism such as Google IDs.
(There are of course other benefits in Web IDs outside the security as
such, in particular data linkage and independence from identity provider.)
Best wishes,
Bruno.
More information about the foaf-protocols
mailing list