Re: "Identity" - is a modal notion, the matrix & definition

> On 4 Jun 2017, at 10:19, David Chadwick <D.W.Chadwick@kent.ac.uk> wrote:
> 
> 
> 
> On 03/06/2017 09:32, Henry Story wrote:
>> 
>>> On 2 Jun 2017, at 18:13, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
>>> 
>>> 
>>> On 02/06/2017 15:57, Henry Story wrote:
>>>> 
>>>>> On 2 Jun 2017, at 14:37, David Chadwick <D.W.Chadwick@kent.ac.uk
>>>>> <mailto:D.W.Chadwick@kent.ac.uk>> wrote:
>>>>> 
>>>>> My take on identity (or more properly the process of identifying an
>>>>> entity) is that it is needed by everyone and everything for the
>>>>> functional purpose of authorisation, which is the most generic of all
>>>>> functions. It encapsulates all possible actions, including tracking
>>>>> (from Joe's narrower definition). All actions need to be
>>>>> authorised/controlled, thus they need to identify the actors.
>>>>> 
>>>>> I identify you to decide whether I want to have or continue a
>>>>> relationship with you (and not with someone else).
>>>>> 
>>>>> Governments identify us to decide if we allowed to be citizens, drive
>>>>> cars, have health care etc.
>>>>> 
>>>>> Web services identify us to provide us with a service.
>>>>> 
>>>>> I am hard pushed to find any use of 'identity' that does not have
>>>>> authorisation as the base requirement.
>>>>> 
>>>>> Examples that you might think are not related to authorisation, are
>>>>> identifying celebrities, identifying inanimate objects, identifying
>>>>> criminals from mug shots. Looking at each one of these in more detail:
>>>>> 
>>>>> I identify celebrities to decide whether I want to follow them, read
>>>>> about them, or ignore them etc. Each of my actions require
>>>>> authorisation, (by my brain) and thus I need to identify who is the
>>>>> person in the magazine to decide whether to read further about them or
>>>>> turn the page and ignore them.
>>>>> 
>>>>> I identify inanimate objects to decide whether to ignore them, pick them
>>>>> up, switch them on etc. If I cannot identify one object from another
>>>>> then I cannot decide what to do with it (i.e. an access control decision).
>>>>> 
>>>>> I see a picture of a criminal on a police wanted poster. I identify him
>>>>> to decide whether to phone the police or not when I see a stranger
>>>>> walking down the street who may or may not match the mugshot.
>>>>> 
>>>>> So I strongly believe that we identify entities in order to authorise
>>>>> actions by them or on them (depending upon whether they are the subject
>>>>> or object of the action).
>>>>> 
>>>>> I would be pleased to hear from anyone who can specify a purpose of
>>>>> identity/identification that does not involve authorisation.
>>>> 
>>>> 
>>>> I can't quite tell if this is the result of a professional deformation
>>>> from someone who has worked for years in this area or if it is brilliant :-)
>>> 
>>> 
>>> Well actually I have Ron Rivest to thank for this brilliance, because he
>>> showed me the light back in the 1990s, when he said 'I do not care who
>>> you are, I only care what you can do'. i.e. authorisation is the
>>> important factor, not authentication. And that is when I switched from
>>> PKI to PMI (and built PERMIS).
>> 
>> Could it be that both are important and that they work together? The guard 
>> needs to know that some Agent A that is at the other end of the connection 
>> is part of some group that has certain access rights. So there is identification
>> - that agent A - and there is then decision as to whether it is part of the group,
>> whether it has the required type.
> 
> Actually identification is not the same as authentication but the two do
> get confused.
> Identification is essential for both authn and authz.
> Identification for authn says who you are (uniquely)
> Identification for authz says what you can do, without knowing who you
> are uniquely, by indicating what class or group you are a member of. You
> inherit the rights of the group by virtue of your membership.
> 
> (At its extreme you could say that authn is the same as authz when every
> entity is in their own group of size 1, and indeed this is how a lot of
> ICT systems have traditionally been built).

I suggest using a very very minimal, near mathematical notion of identity
that covers all cases, and that will allow us to reduce the noise and confusion
in the identity marketplace: something  along the lines of

  the identity of two object x, y of type A is given by a proof that
  x = y 
  
  In our case we are speaking of Agents, which are processes over time,
so this will often require proving that an interaction at time t1 is with the same
agent as another interaction at time t2. 

This is what allows us then to have as wide and as minimal a notion of 
identity as needed for each particular case.   

For example we can be satisfied that the tcp connection identifies an agent
from the beginning of the tcp  connection to the end of it, with all the more 
certainty if we use TLS.

If the tcp or tls session expires the server will no longer be able
to know from that information alone if another tcp/tls session is with the same
agent, unless it received additional information such as a cookie.

Here the notion of  identification in both authn and authz are the same. 
But you are right there is a slight difference of usage, though I think it is 
actually not quite as strong as it seems.  

One can following the pattern used by FIDO and get a different public 
key for each server one connects to, making such a key essentially 
a very strong cookie. This identifies me to the server as the owner of the key.

[] a foaf:Agent;
   cert:key key20 . # where the key info is detailed somewhere else 

the subject of those two statements is the blank node [] which means it
does not have a name. But as the cert:key relation is inverse functional,
we know that it actually uniquely identifies one agent, across sessions.
Ie. if the server keeps in its database information such as the following 
two relations (triples)

_:sess1Agent cert:key key20 .
 _:sess2Agent cert:key key20 .

then it can deduce that 

_:sess1Agent = _:sess2Agent .

I suppose most credentials will be something of the form of a signed statement
by some agent A that another agent S has a set of properties. In order for
any agent S to be able to prove that it is the subject of the statement such
certificates will need to use public keys to identify them in the same way. That 
public key could be the FIDO key mentioned above. 

so Imagine we have a signed statement by the DMV that some user is an Authorized Driver.
This could be written as the following two relations:

_:s cert:key key20 .
_:s a us:AuthorizedDriver .

If the server receives this statement and verifies it as having come from the DMV
it will be in the position to come to the conclusion that

_:sess1Agent = _:s .
_:s a us:AuthorizedDriver . 


So again we see that certificates end up containing a form of methamatical identity
statement, that is pretty uncontroversial.

My guess is that you would take WebID-TLS to be a form of Authentication, 
https://www.w3.org/2005/Incubator/webid/spec/tls/ <https://www.w3.org/2005/Incubator/webid/spec/tls/>
but really it is not much more than another identity statement such as

_:sess1Agent cert:key key20 .
<http://bblfish.net/people/henry/card#me <http://bblfish.net/people/henry/card#me>> cert:key key20 .

and deducing from those that

_:sess1Agent = <http://bblfish.net/people/henry/card#me <http://bblfish.net/people/henry/card#me>> .

I would therefore make the following distinction between Authentication
and Authorization. 

Start with an Authorization rule: it states that an agent of a certain type is allowed
to do a certain thing.

Authentication is finding a handle on the agent that allows one to tie it to properties that
allow one to deduce that it belongs to the type of things that the Authorization rule allows
it to do.

That requires identification of a description such as "The subject x at the end of the tls connection"
with this other name that has a certain property that allows it to do the requested action. So in the
end we have 

_:x a us:AuthorizedDriver .

which allows us to deduce that _:x can read a certain document.


> 
>> 
>> Let is consider a few limit cases.
>> 
>> 1) the agent at the other end  of the connection - anonymous at this point, 
>> may have access to the resource, because the resource is public. The guard
>> knows that any agent that connects is part of the class of agents. Hence
>> it knows that it satisfies the access rule, so it can give access.
> 
> because every entity is a member of the public class

yes, the class of all Agents.

> 
>> 
>> 2) The resource is a paying resource that requires 2c micropayment. The agent at this
>> point is anonymous and there is no record of it having paid, so the guard rejects the
>> request with a 402 Payment Required. The client then sends a 2c coin in the new
>> response somehow. The Guard now knows that the agent at the end of the connection 
>> is part of the class of agents that have paid for the resource, (perhaps he gives 
>> him a cookie to avoid the user having to pay twice), and gives him access to the 
>> request article on micropayments. 
> 
> You can regard the 2c coin as proving membership of the group of
> entities that have paid 2c.

exactly. Note that in the case of bitcoin this actually seems to involve as far
as I know each user having his own public key.

> 
>> 
>> 3) Can view the party invitation only the friends of friends of the organizer. The access
>> control rule which would be written out in Description Logic as 
>> 
>> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>> 
>> # for reference on OWL see https://www.w3.org/TR/2012/REC-owl2-quick-reference-20121211/
>> # and a whole list of standards see https://www.w3.org/standards/techs/owl#w3c_all
>> 
>> # the friend of a friend relation, is true of things that are related once by foaf:knows or twice
>> :foaf owl:subPropertyOf foaf:knows,
>>                        [ owl:propertyChainAxiom (foaf:knows foaf:knows) ].
>> 
>> #The MyFOAF class contains all those agents that are :foaf related to me.
>> :MyFOAF owl:equivalentClass [ a owl:Restriction;
>>                              owl:onProperty [ owl:inverseOf :foaf ];
>>                              owl:hasValue <http://bblfish.net/people/henry/card#me>  ].

Note: the above is not the full access control rule. That is just the definition of :MyFOAF class.
The access control rule would then need to describe what can be accessed by whome.

<#authorization2>
    a acl:Authorization;
    acl:accessTo </shared-file1>;
    acl:mode acl:Read;
    acl:agentGroup :MyFOAF .


>> 
>> Now the client who connects may see this access control rule and determine that he is a member
>> of the group and that the server accepts both WebID-TLS or OpenID authentication, and so at this
>> point uses OpenID as it is more convenient from the machine he is using. The server can then tie
>> the openId and find out that the user is indeed a friend of a friend. Here we use a pseudonym to
>> authenticate and get access to the invitation
> 
> this is an example of delegation of authority where the organiser is the
> SoA/AA/IdP/root of trust. He provides the delegation rule (friend of
> friend) which is the same as delegation depth of 2. The organiser
> implicitly delegates access to his friends group, and each of them
> implicitly delegate to their friends. DoA is reasonably well understood
> in the authz world, though it quickly becomes extremely complex when one
> takes into account revocation and long delegation chains.

yes, though thought of that way the whole of the Linked Data web is  a work of 
delegating authority, of definitions to others. Another way to look at the web of
data  is a set of linked descriptions where different organizations or agents,
are responsible for different parts of the data.

The access control rule  itself is just a description stating what types of
agents can do what types of things. The role of the Guard is then to verify
in one way or another that a specific agent at the end of the connection is 
belongs to the group that is allowed to do that action. For that the guard can
follow the links of relations and build up at regular intervals a set of agent names
or descriptions that can authenticate, or (not exclusive) it could receive from
the client a credential stating that the agent at the end of the connection was
indeed a friend.

By splitting description and verification, one can allow any number of 
verification procedures to be developed.

But yes, pragmatically one is going to be limited to certain length of chain of
foaf:knows, if only because after 6 links we would have the equivalent of all people,
i.e. foaf:Agent, the public resource (which would actually be the easiest to calculate).

> 
>> 
>> 4) I'll leave it as an exercise to come up with examples requiring credentials
>>  (which are somewhat between 2 and 3)
>> 
> 
> Your DoA is static, in that the groups are pre-assigned in the friends
> relationship before the access rule (friend of friend is defined). If
> you use credentials instead, these would be dynamically passed from user
> to user, and the group would dynamically grow as the credentials were
> delegated from one user to another.

I don't think the linked data network is static, anymore than the web is
static. People can add foaf:knows relations to their profiles at any time 
(and even notify servers of it). 

> 
> Another way of looking at it, is that every link in your RDF graph could
> become a dynamically issued credential in the delegated credential model.

yes, though it would be much more difficult to set up a system to later
for people to do the equivalent of removing someone from a foaf file. The 
richness of the web of links would also get completely lost.

The other way to think of it is is that the data in sets of credentials could
be put together and placed on the web in a linkable way. 

And of course one could use both: place information on the web in the
form of linked data - with potential access control restrictions - and also
give out credentials for some where that is not practical or where there
may be a strengthened privacy ground for avoiding that.

That is why having RDF in both of these technologies would be very neat.

> 
> But I do not believe we are covering credential delegation in the VC
> work (please correct me if I am wrong).

Well the friend of a friend relation is not so much credential delegation 
as me specifying the people who I am willing to trust on statements of who 
their friends are, and so my foaf: namely my friends. I can do this via 
linked data or via credentials or both.

But the Access Control Rule remains the same: a description of what group
of people can do what action, irrespective of whether I discover this fact
for a particular user through linked data or credentials.


> 
> regards
> 
> David
> 
>>> 
>>> 
>>>> 
>>>> The idea seems a bit stretched for mathematical objects. What would
>>>> access control to
>>>> mathematical objects be?
>>>> 
>>>> There is certainly something very important to natural selection for
>>>> animals of all types 
>>>> to be able to discriminate if something is of a type or not. Is this a
>>>> poisonous mushroom or
>>>> a tasty one? Is this object stable or is it going to fall over if I lean
>>>> on it? Is that person coming
>>>> to me a friend or a foe? (asked in a war like situation)
>>>> 
>>>> Just to take the last one: we have some x identified of largish agent
>>>> call it x is moving over in 
>>>> that direction with respect to us. We are in a war situation. Is it an
>>>> animal (pig, fox, deer, ?)  or 
>>>> is it a human?  We look and we  start to get enough information to be
>>>> able to discriminate 
>>>> more carefully. Soon we  can see that it is a human. So our alert level
>>>> rises, since we don't yet know 
>>>> if it is a friend or an enemy.  After looking more carefully we
>>>> recognize some element of the uniform, 
>>>> which indicates that it is an enemy soldier. So that would tend to
>>>> indicate very strongly that it is a foe. 
>>>> I don't in this situation actually need to identify x any further to
>>>> act. I don't need to know it's name,
>>>> phone number, email address, mother name, etc... Depending on the
>>>> gravity time I am allowed to 
>>>> think before being myself in danger I may have to act now just on that. 
>>> 
>>> thankyou for confirming my assertion that identification is ultimately
>>> about authorisation. You have now performed sufficient identification to
>>> be authorised to fire your gun. However, your humanity may determine
>>> that you do not want to kill someone on such sparse identity
>>> information, and you may choose to wait until you have more identity
>>> information. But that is your choice and it does not ultimately effect
>>> my thesis.
>>> 
>>> 
>>>> 
>>>> I may have a bit more time and relay this information to someone else
>>>> who has a different angle on the situation
>>>> and they can calculate where the person is given the directions I gave
>>>> with respect to me. From 
>>>> their angle they can (dis)confirm the relation of x to the type of
>>>> our:EnemyCombatant. Of course 
>>>> x is very likely moving and so changing its relation to other things as
>>>> we are trying to diagnose the situation.
>>>> We need to figure out very fast if we need to act or if we can escape
>>>> its attention unharmed 
>>>> and follow x to see what it is doing, i.e. to put it in relation to
>>>> other enemy combatants, to work
>>>> out what its plan is, and so what their plan is, .... We may be able to
>>>> send a mosquito sized drone
>>>> all the way to it, to spy on all its information exchanges with its
>>>> headquarters, and so gather its e-mail
>>>> address, home page, telephone number, mother and father's name etc... We
>>>> will then have identified the 
>>>> individual much more precisely. Perhaps we will then know enough that we
>>>> can convince it to switch sides.
>>>> 
>>>> But perhaps we don't get all that information and it is only years after
>>>> the war that having gotten hold
>>>> of the enemy logs that we can work out that information and get that
>>>> deeper identity which will allow us
>>>> to let x's family know what happened that day.
>>>> 
>>>> Still in order to do that we have also identified a number of objects in
>>>> the background as trees, roads,
>>>> lakes, bushes, all in some relation to us and the background mountains.
>>>> Each of these objects we can
>>>> categorize in some way or other, and this can be used to guide our
>>>> action with respect to them. But
>>>> perhaps that is just because information, action and strategies are very
>>>> strongly linked. 
>>>> 
>>>> Types are often thought of as ways of discriminating objects. And to act
>>>> successfully we need to discriminate 
>>>> correctly.
>>> 
>>> Correct. And types are the fundamental objects in RBAC and ABAC. And
>>> guess how types are catagorised? By their attributes.
>> 
>> It Description Logics and OWL you can define a class from the attributes
>> as I have done above with the :foaf relation. One can also describe classes
>> as subclasses, intersections, unions etc of other classes. Attributes can be
>> inherited somewhat like in OO programming - though in a declarative consistent
>> style. In RDF relations are the basic thing: to declare an object to be of a type
>> one relates it to that type. To specify an attribute one specifies a relation of the
>> object to the attribute value. This consistency and uniformity removes a lot
>> of complexity and simplifies the model to the maximum, leaving just the unavoidable
>> computational complexity questions, that have already been classified and 
>> dealt with in large part by logicians  and mathematicians.
>> 
>>> 
>>>> 
>>>> It is certainly true that as far as credentials go, the main use of them
>>>> will be access control (I think). 
>>>> That could certainly help narrow the focus somewhat of our investigation.
>>>> 
>>>> I think we can go further and then defined type of action an access
>>>> control decision is. An act of
>>>> access control is I think is an action that a Guard does that follows
>>>> the following pattern:
>>>> Is the thing x in front of me, at the other end of the connection,
>>>> etc... allowed to act on object y 
>>>> that I control? What types of objects are allowed to do that action? Can
>>>> that x prove to me that it is of that type?
>>>> And we are interested for proofs of that type to be done via a
>>>> credential of some form, where the x
>>>> can prove that it is the object that is spoken of in the credential
>>>> shown to us - the x can work out
>>>> somehow which credential is the most appropriate to show. 
>>>> 
>>>> This seems to be getting closer to something useful. 
>>> 
>>> Great. Because ultimately if we build a technically beautiful construct
>>> that has all the latest state of the art, but is not useful, then it
>>> will not be used and it will become shelf-ware. I believe that VCs are
>>> incredibly useful. I use the physical equivalent everyday and I cannot
>>> live without them. They are of course plastic cards.
>>> 
>>> regards
>>> 
>>> David
>> 
>>