Re: "Identity" - is a modal notion and the matrix

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

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

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

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

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

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.

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

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

Received on Sunday, 4 June 2017 08:19:53 UTC