- From: David Chadwick <D.W.Chadwick@kent.ac.uk>
- Date: Tue, 6 Jun 2017 17:06:18 +0100
- To: Henry Story <henry.story@bblfish.net>
- Cc: public-credentials@w3.org
On 04/06/2017 15:54, Henry Story wrote: > >> On 4 Jun 2017, at 10:19, David Chadwick <D.W.Chadwick@kent.ac.uk >> <mailto: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 >>>> <mailto: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> >>>>>> <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/ > but really it is not much more than another identity statement such as > > _:sess1Agent cert:key key20 . > <http://bblfish.net/people/henry/card#me> cert:key key20 . > > and deducing from those that > > _:sess1Agent = <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. Quite remarkable, in that you have arrived at the FIDO Authz model I developed some time ago and that my colleagues in Toulouse built last year. I gave a talk about this at EIC 2017 this year. So I agree with everything you say above. > > >> >>> >>> 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 . I had implicitly assumed the above, since you said that access was given to your friends of friends. > > > >>> >>> 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. Yes, each organisation that issues a VC to an entity could instead (or as well as) add a link to that entity where the relationship is the type of VC that it has issued. But it is too coarse grained I think for delegation of authority. Either you would need to make different sets of links for different resources e.g. my web page friends, my CV friends, my bank details friends etc. and then have a simple access control rule specifying which set of friends can access each resource, or you would have one set of links (friends) and then very complex access control rules for each resource that would pare the tree down to just those that you wanted to access each resource (and even that would not work because you would need to have disjoint branches in the tree to cover all cases) > > 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. This is essentially what ABAC and RBAC do. They issue attributes (or roles) to users, and then the resource determines how possession of the attribute (or role) is verified, and what privileges each attribute possesses. > > 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). This is why I think the method is too coarse grained. > >> >>> >>> 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. I dont think it is a good idea to use a technology designed for one thing (like linking friends) to be used for another thing like access control, since they are essentially different. There is bound to be a mismatch between them. (In the same way that it is not a good idea to put authz attributes in PKI credentials). > > That is why having RDF in both of these technologies would be very neat. I can see that it would be neat in some cases for service providers to put RDF links to the credentials they accept. Kinda like publishing your security policy for the public to see (aka credit card stickers in shop windows). But in other cases it would be a bad idea, when you dont want the public to know what credentials you accept. > >> >> 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. The other issue to consider is, do people want to publish which credentials they have? If not then they would not want to have RDF links to them. regards David > > >> >> 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 Tuesday, 6 June 2017 16:06:57 UTC