[foaf-protocols] the logic of foaf+ssl = identity

[Bruno Harbulot]

Story Henry wrote:
> I'll cut up the replies into a few smaller pieces. Here on Identity.
> 
> (( Ps. The logical part this email, which I will answer to later,is 
> making a lot of sense. I think we are converging. I am just answering 
> this part here first because it is easy to answer and could clear up 
> other issues along the awy. ))
> 
> On 6 Mar 2009, at 14:22, Bruno Harbulot wrote:

>> The bit we're trying to prove, (4) above, is exactly the same problem 
>> as self-registration by e-mail address. We delegate responsibility to 
>> that ID. We don't actually know what the user is (he's outside the 
>> system), we just know that he has control over this ID.
> 
> Interestingly enough on the issue of control, foaf+ssl can work without 
> my controling the URI. It is quite possible to imagine that the 
> government should give out crypto USB keys, which would create 
> certificates for me, with my government URL on it. So I would neither 
> have control over the subject alternative name, nor over the public key.

Yes, but as I said in my previous message, the purpose of authentication 
is to prove that the user has the relevant credentials to use the ID. 
It's the responsibility of the ID that's at stake.
It is a matter of control: whoever controls the URI may choose to 
delegate the right to use this URI to any individual.
In FOAF+SSL, whoever controls the WebID URI delegates the right to use 
this WebID to whoever has the private key that corresponds to the public 
key given when dereferencing the WebID.


> No I think we are trying to find out when the server should serve a 
> given resource. We are trying to work out what reasoning it can have 
> that is correct, useful and on which we can build some powerful 
> distributed trust technologies

Are you talking of the protected server (Juliet's) here? That would be 
going back into the authorisation territory. It's true it's the goal, 
but the aim of authentication is to bind an identifier to the subject



> Well as we have discussed a lot before, I think that is part of 
> identification. Authentication comes into it, especially when there is a 
> CA in the loop, and you need to authentify the CA, which is the entity 
> you trust and so that enables you to pass from the

> the cert says { s r b }
> 
> to
> 
> s r b .
> 
> Authentication comes from 'proving authorship'. So in the identification 
> step in foaf+ssl we have a very minimal version of that, in that we look 
> for a self signed certificate, but in our case that does not enable us 
> to do the above disquotation, because we are not sure we trust the agent 
> yet.

Well, authentication consists of verifying that the user is allowed to 
use the identity he claims to have. The verification has to come from 
whoever has authority in saying who can use that identity: the CA in a 
PKI or the WebID URI in FOAF+SSL. It's that authority which performs the 
verification and allows the user to use this identity. That's when the 
authentication is done.

The CA model ca be summarised as this:

  (1) For each ?ca, trusted(?ca) => { for each ?cert, ?cert issuedBy ?ca 
=> { for each ?st, ?cert says ?st => ?ca says ?st } }


When a certificate is presented, you get those to claims:

  (c2) cert says { for each ?x, ?x hasPrivateKeyFor publicKey <=> ?x is 
subjectDN }
  (c3) cert says { cert issuedBy ca }

If you already know (not trust yet) ca (an axiom in this system), you 
can verify the certificate signature. (c3) was a hint to look for the 
right issuer amongst your known CAs. This produces a new fact:

   (3) cert issuedBy ca

Because you trust this particular ca, using (1), you turn (c2) into:
  (c2') ca says { for each ?x, ?x hasPrivateKeyFor publicKey <=> ?x is 
subjectDN }


Because you recognised that this ca has authority on this subjectDN 
(same prefix /C=xxx/O=xxx/OU=/xxx...), you can trust what the ca says 
regarding this subjectDN, in particular what it requires from Juliet to 
check for the ca to accept responsibility for authenticating that ID: 
checking that the user has the private key.



Best wishes,

Bruno.