[foaf-protocols] FOAF+SSL trust -- was delegation
Bruno.Harbulot at manchester.ac.uk
Wed Apr 29 10:50:16 CEST 2009
Kingsley Idehen wrote:
> Bruno Harbulot wrote:
>>>> (This comment by someone called "bong" talks of the very same problem
>>>> for OpenID [*].)
>>> Bong is talking about something different.
>> It's the very same problem, at the user authentication level.
>>> He is saying that OpenId does not come with any notion of trust.
>>> OpenID has all the technical details worked out in terms of how to
>>> exchange authentication information and credential information. But
>>> OpenID has no technology that conveys trust. And trust is not
>>> something that can be done technically. It’s a business agreement.
>>> With FOAF+SSL we have the authentication piece.
>> Exactly, but you have to trust what you do the authentication with
>> *before* you do the authentication (and keep a record of how that was
>> done for auditing purposes). That trust comes with signed information
>> (or information you trust by another mechanism), not by just
>> dereferencing a URI you don't know anything about.
> I am assuming that you are implying the quality of a self signed
> certificate is the issue here? Whereas one signed by a proper CA
> authority would make such identity legally non-repudiatable, right?
More or less. It's not really the self-signed certificate as such, but
the degree of trust in who certifies the assertions (in particular the
link between Web ID and public key, which is what's used for the
A self-signed certificate on its own is worthless.
A FOAF+SSL certificate verified by dereferencing is worth the assertion
made by the dereferenced URI (at best, if that dereferencing has been
done securely). This is better than self-signed, since you get something
as tangible as the hosting of the URI. (In particular, you shouldn't
make authorisation decisions that will have an impact after the
expiration date of the domain at the time the verification is made.)
A FOAF+SSL certificate verified by checking that someone certified the
link between the Web ID and its public key is as good as you can trust
who made that certification. There may be intermediaries in this
process. You can indeed build something as good as a proper CA out of
this if required (in particular for non-repudiation in a legal sense,
where you can attach the entities making the assertions to legal
entities). These entities might not be liable for the actions of the
user, but for the way the user is bound to an actual person (or legal
Of course, the same issue would come for the other information you may
get for making the authorisation decision. It's just that if you can't
do it for the authentication part (which binds the actual client to a
Web ID, via the public key), there's no point going any further in
exploring what you may find out about that Web ID (except what may
assert with a better certification level this association between the
Web ID and its public key).
More information about the foaf-protocols