[foaf-protocols] FOAF+SSL trust -- was delegation

Bruno Harbulot Bruno.Harbulot at manchester.ac.uk
Wed Apr 29 10:50:16 CEST 2009


Hi Kingsley,

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.
>>   
> Bruno,
> 
> 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 
authentication).

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 
entity itself).


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).


Best wishes,

Bruno.


More information about the foaf-protocols mailing list