Guidelines for attribute determination for policies

For the automated execution of rules in an attribute based access control (ABAC) system we need to determine the attributes of each of the elements in the rules. Four different types of attribute are used in constructing the policy rules. 1. Subject attributes 2. Action attributes 3. Resource attributes 4. Environment attributes. Subject attributes identify the users who are to be granted or denied access. Action attributes describe the actions that are being controlled. Resource attributes describe the features of the protected resources (i.e. the personal data), such as: resource type, data issuer, data subject, date of creation etc. Environmental attributes describe the context in which the rule applies, such as the time of a day, location etc. These four types of attribute are also used to describe a user’s request to access a resource, and are passed to the PDP in the request context by the application. PDPs compare the attributes of

88

the user’s request with those of the rules to determine whether an access should be granted or not. Each resource in the system is identified by a unique RID (Resource identifier) (see Section 3.3.2.5). Each resource has some attributes associated with it and these attributes are stored safely with the resource (the personal data) and added by the PEP (Policy Enforcement Point) to the request context and passed to the PDP when a request for accessing it is received.

o The data subject is determined based on his/her set of identifying attributes (such as name and address, e-mail address, NI number, NHS Number etc.) given at the time the personal data are submitted or during the registration of the subject with the controller for a service. These identifying attributes are stored as resource’s attributes of the resource to which the data subject is related. The Legal PDP checks if these identifying attributes match with those of the requester (passed with the request context as subject attributes) to determine whether the requester is the data subject or not for the requested resource. In the current implementation of Legal rules the following sets of uniquely identifying attributes are used: {{name} and {address}}, {e-mail address}, or {NHS Number}, but these sets are configurable and can be changed and extended as needed by the application. The data subject should be able to choose any of these to identify her/himself.

o ResourceType is a resource attribute that holds the type of the data, such as medical data, and is placed as an attribute of the resource by the issuer of the data. Only the issuer can modify the ResourceType of that data. An ontology is needed to classify the different types of personal data, and an ontology mapping server (e.g. as described in (Fatema, Chadwick and Lievens 2011)) may be used to hold it and be able to determine whether a resource type is a type of personal data or not. The ontology server may also determine the relationship among these data types; for example all the medical data types are subclasses of personal data. o PurposeOfCollection (mentioned in rule 1 of Table A1.2 and A1.3 of Appendix 1) is another resource attribute that states the set of purposes for which the data were collected from the data subject. It is set by the application when the data are first collected from the data subject. The Legal PDP matches this set with the purposes stated by the requester in the request context.

o ValidityTime (mentioned in rule 3 of Table A1.2 and A1.3.) is another resource attribute collected from the issuer or data subject. A default value can also be set by the controller if the issuer or data subject does not provide a value for it. The controller needs to mention the default validity time of the data when collecting them. The Legal PDP matches the time of the access request (passed as an environment attribute of the request context) with the ValidityTime of the requested data.

o Treating Medical Professional (mentioned in rule 12 of Table A1.2 and rule 11 of Table A1.3 ) is identified by an identifying attribute (e.g. PhysicianID) stored in the medical record of the patient (as a resource attribute). The value of this attribute must match that of the equivalent attribute of the requester, in order for the requester to be identified as the Treating Medical Professional. The name of this attribute is configurable in the Legal policy.

o Social Security Authority, Medical Professional/ Supervisory Authority are Role attributes (mentioned in rules 8, 9, 17, 23, 26 and 27 of Table A1.2 and rules 8, 9, 15, 17 and 18 of

89

Table A1.3) provided by the trusted Attribute Authorities. Who are the trusted authorities for which roles depends upon the application, and these are configurable values in the Legal policy.

o LegalObjection, MedicalObjection, NationalSecurityIssue and Economic/ FinancialIssue(mentioned in the rule 16 of Table A1.2 and rule 14 of Table A1.3) are Boolean attributes of a resource which are used to flag the personal data that are not accessible to the data subject due to the national legislation which contains an exception to the data subject’s right of access. For example, a doctor may have the ability to invoke a MedicalObjection to prevent the patient from accessing certain information; or there is legal issue such that seeing the data by the data subject may harm a legal process such as a legal investigation. These attributes can only be issued by the designated (trusted) authorities. Note: If only one attribute (e.g. LegalObjection) was used there might be a situation that a LegalObjection set by one authority for one purpose would be overridden by another authority for a different purpose.

o DataAccessMandate/ DataTransferMandate (mentioned in rules 7 and 22 of Table A1.2 and rules 7 and 16e of Table A1.3) are credentials which can only be obtained by a requester following the appropriate legal procedure. Conceptually these are treated as subject attributes in the policy, so that if a requester possesses the appropriate mandate attribute he/she inherits the permissions assigned to the mandate (the DataAccessMandate is assigned for allowing access to personal data and the DataTransferMandate is assigned for allowing the transfer of personal data). These legal mandates are issued by various trusted Attribute Authorities and both the authorities and mandate types are configurable to suit the application. The requester (or the Attribute Authority) presents the Mandate to the application which either verifies it using a Credential Validation Service and passes the valid attribute to the PDP as a subject attribute, or passes it to the PDP as a subject credential for the latter to verify.

o PartyOfContract and SubjectOfContract, AuthorisedRequester (mentioned in rules 5,19 and 20 of Table A1.2 and rules 5 and 16 of Table A1.3) are attributes of a contract. A contract is defined to be a digitally signed XML document which has an element called PartyOfContract containing the identifying attributes (IDAs) of the people who have signed it and information of the organisation who are parties of the contract, and an element called SubjectOfContract containing the IDAs of the data subject. AuthorisedRequester contains the IDAs of the persons who are allowed to access the data due to a contract. When a requester wants to access a personal data item for a purpose related to the performance of a contract, s/he presents the contract or the unique contract identifier to the system if the system already has that (in cases where the controller is also a party of the contract then the controller’s system should have the contract in its repository). For validating contracts, a trusted component called the Contract Validation Service (ConVS) is added to the system (discussed in detail in Chapter 3). If a contract is valid the ConVS passes information such as validity time, resource type and the identifying attributes of the authorised requester, parties and subject of the contract. This information is used by the Legal PDP while authorising an access request based on a contract.

90

o SubjectConsentsToTransferTo (mentioned in rule 18 of Table A1.2 and rule 16 of Table A1.3) is an environment attribute set by the application to the IDA of the requester when the data subject consents to transfer his/her personal data to a requester. A requester can send a request for consent (via the application) to the data subject for transferring his/her personal data. If the data subject agrees to the transfer s/he can give his/her consent via the application (e.g. by clicking a button or ticking a box). This consent is stored by the application and when the requester requests the data this consent (in the form of SubjectConsentsToTransferTo environment attribute) is appended to the request context by the application.

o SubjectRequestedToProcess and AllowedPartyToProcessData (mentioned in rule 6 of Table A1.2 and rule 6 of Table A1.3) these two attributes are used to indicate that the data subject of a personal data has allowed a person or party to process a personal data item prior to entering into a contract. These two attributes can be obtained from a digitally signed document by the data subject or can be obtained by the application (via a process similar to obtaining the previous attribute). The attribute SubjectRequestedToProcess contains the type of data the data subject is allowing to process and this is matched against the requested resource type. The attribute AllowedPartyToProcessData contains the IDA of the person or party the data subject is allowing to process the data for the purpose of entering into a contract. This value is matched against the IDA presented by the requester.

o SubjectRequestedToTransfer and AllowedPartyToTransferData (mentioned in rule 21 of Table A1.2 and rule 16 of Table A1.3) these two attributes are used to indicate that the data subject of a personal data has allowed a person or party to transfer a personal data item for the implementation of the pre contractual measure. These two attributes can be obtained from a digitally signed document by the data subject or can be obtained by the application (via

a process similar to obtaining the previous attribute). The attribute

SubjectRequestedToTransfer contains the type of data the data subject is allowing to process

and this is matched against the requested resource type. The attribute

AllowedPartyToTransferData contains the IDA of the person or party the data subject is allowing transferring the data for the purpose of entering into a contract. This value is matched against the IDA presented by the requester.

o AdequateSafeguard (mentioned in rule 25 of Table A1.2 and rule 16 of Table A1.3) is another contextual attribute used by the current controller to indicate that the destination controller has agreed to provide adequate safeguards to the personal data when the transfer of personal data is being made to a country not having an adequate level of protection. For example, the current controller may have a contract with the destination controller stating that adequate safeguards will be provided.