[foaf-protocols] identification, authentication and authorization

Henry Story Henry.Story at Sun.COM
Mon Mar 2 13:13:28 CET 2009

On 28 Feb 2009, at 19:44, Bruno Harbulot wrote:
> Hi Henry,
> Henry Story wrote:
>> In UML diagram presented here
>>  http://blogs.sun.com/bblfish/entry/foaf_ssl_adding_security_to
>> How do we name the stages?
>> [snip]
> I'd like to suggest the following definitions:
> Authentication is the action of verifying the identity of the remote
> user. Authorisation consists of allowing or denying access or  
> operation
> on a given resource, based on the identity obtained during the
> authentication. Authentication not only checks that the remote user is
> who he or she claims to be, it also associates this user with an
> identity on the system. This identity is built from the point of  
> view of
> the protected system: it may include roles, account information or  
> other
> attributes that define the identity of the user on this system (the  
> user
> might not be aware of all these attributes). In FOAF+SSL, the identity
> consists both of the foaf:Person URI and of its position and degree of
> trust in the Web-of-Trust built from FOAF files.

> Identification is part of the authentication process, but the result
> authentication process implies that the identity has been verified.
> The diagram in
> <http://blogs.sun.com/bblfish/entry/foaf_ssl_adding_security_to> could
> be split into two, since it represents two different actions:
>   (a) adding someone as a trusted person (and verifying this person's
> identity partly out of band anyway),
>   (b) authenticating someone via your FOAF-based network of trust.
> I still think that de-referencing the URI to check the public key  
> isn't
> particularly interesting, except the first time.

It is very useful afterwards too. For example if someone steals my  
private key, I can go and remove the association between my WebId and  
my public key. We do here in one step something that is a lot more  
complicated in current systems, which require certificate revocation  

This is what will enable us to create temporary certificates for  
public terminals.

> Verifying that the public key obtained from the URI matches the one
> presented by the certificate only confirms that the user really has
> write access to that URI. That's interesting, so far there isn't much
> more than OpenID.

yes, we get the same as with OpenId basic  but for a lot less work.  
1-2 ssl connections as opposed to 9 or so. One should not minimize the  
importance of such a simplification. To make a parallel with  
scientific discoveries: you can do a lot by working on the assumption  
that the earth is flat, or that it is the center of the universe, but  
the maths you get when you take the sun as being the center are so  
much simpler, that a lot of other things become a lot easier to  
understand and calculate.

> This is a bit like self-registering on a web-site and
> having to confirm your e-mail address: even if you e-mail address  
> (which
> is your identifier there) has been verified, you can often enter the
> details you want without them being verified.

yes. So there here too we have 2 things that are distinguished:
   - identification via email
   - trust in whatever else it is that the person says in addition to  
what they said about their e-mail

> In FOAF+SSL, for authentication (except initial registration), what's
> important is how the server you're connecting to is able to verify  
> your
> identity, in particular what your "trust score" is in the FOAF  
> network.

So I think we need to separate the notion of pure foaf+ssl  
identification from the trust score that can later be calculated from  
that Id.

Notice for example that foaf+ssl can also be used in a non web of  
trust way. For example I could go to a web site that just authorizes  
only certain pre set IDs, where these are not determined in a web of  
trust manner - leaving aside here the very plausible argument that all  
trust is based on a web of trust...

There is a notion then of absolute minimal identification: that is  
when presented with a WebId, the server authenticates that ID. In the  
case of the email identification, that is as you describe above what  
you get when someone replies correctly to the e-mail.  In foaf+ssl  
this is the equivalent of verifying that the SSL connection is  
correct, and comparing that to what the ID says about its associated  
public key.

> Let's say I'm Alex, a friend of Bob and Chris is a friend of Bob,  
> but I
> don't know him. I have an access policy which consists of letting the
> friends of my friends into my house.
> For this analogy, we'll assume that the name of an individual is his
> identifier, his picture is his public key, his presence is like using
> his private key, and his a passport/ID-card similar to a certificate  
> by
> an established CA.

Except that with foaf+ssl, the passport is an odd one, because instead  
of being published by a government agency - e.g. the  United States of  
America - it is published by the owner himself :-). (and it is very  
explicit about that!)

It is worth stopping here and noticing just how bizarre foaf+ssl may  
seem to people who are used to the example you put forward. This would  
be like arriving at the border of a country and instead of presenting  
a passport, presenting an A4 paper displaying a picture of oneself, a  
name and signed by oneself. I think the officers at the border would  
laugh out loud at such a stunt.

One could in fact say that the passport example is the paradigmatic  
authentication example, and within that paradigm:

    - it is clear why Certification Authorities are important
    - it is utterly bizarre that someone would present a self signed  

So we are performing what is known here as a paradigm shift.

As there are a lot of different pieces here, let us simplify the  
example down to the core identification piece of foaf+ssl: let us  
leave out for the time being the web of trust piece. Let us say that  
at this party there is a list of IDs of people who get accepted to the  
party: either you are on the list and you are allowed in, or you are  
not, and you can't get in.

	Oddly enough I can make the example even more unbelievable, and yet  
make it more believable simultaneously. Imagine now I come cloaked to  
your party, my face and body fully hidden. I present you with a public  
ID typed on a piece of paper. You say hello, I say hello! On the basis  
of that you let me in with confidence. Do you believe you are going to  
believe this? :-) Is that not even more outrageous than the passport  

  	So let us fill in the picture a little bit. On that piece of paper  
was my cell phone number (but it could also be an email address). You  
check that number on the list, it is indeed on the list, so you call  
that phone number (or send me an email) and I answer the call and say  
hello (reply to the email). Done. All you needed was one of my  
indirect identifiers.

Interestingly enough, this example shows how one could do the  
authorization step before one does the identification step. After all,  
there's no point in doing the identification if the authorization will  
be negative. (though doing the authorization first could leak  
information to untrusted parties about who can attend the party - so  
that may be a reason not to proceed this way)

	What it also shows is how identifiers are key to this process.  
Telephone and email addresses are URLs. All that was required was to  
tie the person in front of you to that URL. In the case of the phone  
number by calling them, in the case of the email by mailing them. And  
in the case of foaf+ssl by GETing that URL.

	The advantage of using a URL identifier, especially of the http  
variety, is that we can then develop a RESTful service, which means  
that it is in accord with the principles for building global,  
distributed, decentralized information networks that can link up  
together easily. Because every resource has a url and can point to any  
other resources in this system, we can easily build a Web. A Web of  
Trust in this case.

This shows I think that the identification step is really key to what  
we are doing, and why the web of trust can build so well on it.

So there is another stage linked to how much one believes what someone  
says. Is his name what he says it is, does he really know the people  
he says he knows, is he truthful about his age, etc... But in our  
simplest example, this was not required to allow him access to the  
party. After all the party could be "Liars united". I think the rest  
depends very much on the resources offered. Showing your passport in a  
car sales shop is not enough to buy a car. They usually do a credit  
check too.


> Someone (X) rings the bell at my house. I don't know him.
> 1. X says he's Chris. I have no clue whether that's true.
> 2. X shows me his passport. Has has put his own signature and it has  
> its
> picture. The picture matches the individual in front of me. The  
> passport
> is authentic.
> All this is similar to de-referencing the URI in the certificate: the
> guarantee that the URI is correct is in fact done because I've  
> retrieved
> the FOAF file at this URI over https, the certificate of which is  
> going
> to be established by a known CA in this case.
> So, at the end of this, I've verified that the guy standing in front  
> of
> me was Chris. Good. But who is Chris?
> 3. Chris says he's a friend of Bob's. I don't know whether this is  
> true.
> He may have a picture of Bob, but anyone can do that.
> Again, this is similar to Chris giving me his FOAF file and who he
> claims he knows. It's not particularly useful so far.
> 4. I know Bob. Since Chris says he knows Bob, asking Bob is a good
> starting point. I call Bob and he e-mails me a picture of Chris  
> (with a
> label saying Chris). I've checked the public key of Chris that Bob  
> knows
> against the public key of Chris (and the actual person). Now, I know
> that Chris is a friend of Bob's. I've identified Chris as being 2 hops
> away in my network of friends, and this information has been verified
> (so the authentication has completed).
> I can now authorise Chris to come in.
> After all this, did I need step 2? Probably not. If I trust Bob to be
> able to introduce Chris to me, checking Chris's passport is somehow
> redundant. It's the same as de-referencing the URI that the client
> presents. It's not particularly useful for finding the position of the
> user in my social network.
> I'll only have verified that X is Chris once I've checked the picture
> sent by Bob, but that's fine.
> The second variation looks like this:
> 1. X says he's Chris. I have no clue whether that's true.
> 3. X says he's a friend of Bob's. I don't know whether this is true.  
> He
> may have a picture of Bob, but anyone can do that.
> 4. I know Bob. Since X says he's Chris and he knows Bob, call Bob  
> asking
> for a picture of Chris, and he e-mails me this picture. I've checked  
> the
> public key of Chris that Bob knows against the public key of X (and  
> the
> actual person). Now, I know that X is called Chris and that he is a
> friend of Bob's. I've identified Chris as being 2 hops away in my
> network of friends, and this information has been verified (so the
> authentication has completed).
> I can now authorise Chris to come in.
> What I do need is to make sure that the picture of Chris that Bob has
> sent me has not been altered. That's why signing FOAF files is  
> important.
> In <http://blogs.sun.com/bblfish/entry/foaf_ssl_adding_security_to>,
> - 4 and 5 are only useful the first time (although there's no harm in
> checking once in a while): it verifies the the user's identifier is  
> correct.
> - 6 is the real authentication step, to verifies the user's identity
> (relatively to Juliet's FOAF network).
> Best wishes,
> Bruno.

More information about the foaf-protocols mailing list