Attribute Certificate Authority

Attribute Certificate Authority

To support Attribute Based Access Control (ABAC) the user has to pass a set of attributes during TCert creation, this attributes will be used during transaction execution to allow the user execute or not execute a code. A mechanism to validate the ownership of attributes is required in order to prove if the attributes passed by the user are correct or not. The Attribute Certificate Authority (ACA) is responsible of validates attributes and returns an ACert (Attribute Certificate) with valid attributes.

ACA will have a DB to hold attributes for each user and affiliation. This DB will be encrypted.

1. userID (The id passed by the user during enroll)
2. affiliation (The entity which user is affiliated)
3. attribute Key (The key used to lookup the attribute for example 'position')
4. attribute value (The value of the attribute for example 'software engineer')
5. valid from (The timestamp from which the attribute is valid )
6. valid to (The timestamp to which the attribute is valid)

ACA API

FLOW

During ECert generation

1. User requests an ECert to ECA
2. ECA creates ECert
3. ECA issues a fetch request (ECert) under TLS signed with the ECA private key to the ACA.
4. This request triggers the ACA mechanism that fetches attribute values from the outside world and populates this inside the database. In this step we do not go to the outside world to get the attributes, instead we will just populate the db with autogenerated (or from a config file) data_.
5. ECA continues the ECert creation a returns the ECert to the user.

During TCert generation

1. When the user needs TCerts to generate a transaction the user requests a batch of TCerts to the TCA, and provides: a. Batch size (i.e. how many TCerts) b. ECert c. List of attributes i.e. i. Company:IBM ii. Position: Software Engineer
2. TCA sends under TLS a request to ACA to get those attributes: a. RequestAttributes() this request contains: i. ECert ii. Company:Hash(IBM) iii. Position: hash(Superman) v. Signed with TCA private key
3. ACA performs a lookup in his internal DB and is going to reply one of the following: a. You do not have any of those attributes (error) b. You have all attributes – returns X.509 certificate with all those attributes and the ECert public key inside the certificate. c. You have a subset of the requested attributes. We will still return an x.509 certificate with just the subset.
4. TCA checks validity period for attributes and updates the list by eliminating those that are expired. Then it will check for case b and c how many (and which ones) of the attributes the user will actually received inside each TCert. This information needs to be returned to the user so the user can decide if the TCerts are useful to him or if he needs to perform further actions (i.e. issue a refreshAttributes command and request a new batch, throw and error or make use of the TCerts as they are).
5. TCA could have other criteria/rule to update the valid list of attributes a. This will not break any legacy stuff
6. TCA creates TCerts and populates it with valid attributes
7. TCA encrypts the attributes with the keys derived from the Preky tree
8. TCA returns the batch of TCert (all TCerts in the batch have the same attributes and the validity period is the same for the entire batch)

Assumptions

1. An Attribute Certificate Authority (ACA) was incorporated to the Membership Services temporarily in order to allow us to mandate how to communicate with it.
2. Currently we are fetching attributes from the configuration file (membersrvc.yml).