[foaf-protocols] identification, authentication and authorization
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
>> How do we name the stages?
> 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
> 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
> attributes that deﬁne the identity of the user on this system (the
> 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 ﬁles.
> 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
> 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
> 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
> 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
> identity, in particular what your "trust score" is in the FOAF
So I think we need to separate the notion of pure foaf+ssl
identification from the trust score that can later be calculated from
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
> 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
> 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
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
> 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
> picture. The picture matches the individual in front of me. The
> 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
> the FOAF file at this URI over https, the certificate of which is
> 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
> 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
> 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
> 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.
> 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
> for a picture of Chris, and he e-mails me this picture. I've checked
> public key of Chris that Bob knows against the public key of X (and
> 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
> 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
> - 6 is the real authentication step, to verifies the user's identity
> (relatively to Juliet's FOAF network).
> Best wishes,
More information about the foaf-protocols