Policies

Different service providers, may need different user attributes depending on the usecase. In some cases, the user’s age might be relevant, while other cases may be focused on possesion of a drivers license or the nationality of the user. The concept of policies is what allows a relying party to specify what should be revealed as part of the vIdP issued JWT token.

The OLYMPUS framework uses simple policies, serialized as JSON objects, to describe the these requested attributes or properties. Policies are comprised of a policyId, used in the dP-ABC approach as a nonce, and a list of predicates. Each predicate defines an operation over a specific attribute, using two mandatory fields (attributeName and operation) and two fields with attribute values that will be necessary depending on the operation (value and extraValue).

• Policy Java class

public class Policy {

	private List<Predicate> predicates;
	private String policyId;

    public Policy(List<Predicate> predicates, String policyId) {
		super();
		this.predicates = predicates;
		this.policyId = policyId;
	}

	public Policy() {
    }

	public List<Predicate> getPredicates() {
		return predicates;
	}

	public void setPredicates(List<Predicate> predicates) {
		this.predicates = predicates;
	}

	public String getPolicyId() {
		return policyId;
	}

	public void setPolicyId(String policyId) {
		this.policyId = policyId;
	}
    
}

• Serialized policy example

{
  "predicates" : [ {
    "attributeName" : "Name",
    "operation" : "REVEAL"
  }, {
    "attributeName" : "Age",
    "operation" : "INRANGE",
    "value" : {
      "attr" : 18,
      "type" : "INTEGER"
    },
    "extraValue" : {
      "attr" : 25,
      "type" : "INTEGER"
    }
  } ],
  "policyId" : "SignedMessage-9235621539"
}

Supported predicates

Current implementation supports predicates for the following operations:

• EQ: Check if corresponding attribute is equal to the value in field value.

• REVEAL: Reveal the value of the corresponding attribute.

• GREATER_THAN: Check if the corresponding attribute is greater or equal than the value in field value.

• LESSTHAN: Check if the corresponding attribute is lesser or equal than the value in field value.

• INRANGE: Check if the corresponding attribute is within the range [value,extraValue].

The last three predicates need to be applied to a “numeric” attribute. Currently, this means it must be an attribute of type Integer or Date. All of these operations are supported by both PESTO token generation and dP-ABCs, except EQ in dP-ABCs (currently, though it could be partially supported by levering attribute revelation).

Range predicates for dates

Usage of these predicates is pretty straightforward. However, date attributes require some extra consideration because of typical use cases for them. Complex proofs of age (or time periods in general) can be created using range (GREATER_THAN, LESSTHAN, INRANGE) predicates, but it is necessary to take into account some ideas.

• If no Age (e.g. 25 years old) attribute is included in the credential (which is better in the long run, allowing more flexibility, avoiding inconsistencies in credential values and real age…), it is necessary to rely on more “static” and “meaningful” attributes like Date of Birth.

• This means “Age” predicates are not as straightforward (e.g., proving someone’s age is over 18 is not possible with a simple Age GREATER_THAN 18 predicate).

• However, it is quite simple to generate a predicate with equivalent meaning using the Date of Birth. We can take today’s date, subtract 18 years (i.e., res = today – 18 years), and prove that the Date of Birth value in the credential, x, fulfils: x <= res.

• The same process can be applied for “LESS THAN” predicates (and consequently, for “IN RANGE”). In the predicate definition, inequalities are inverted (with respect to the “ideal” abstract predicate we want to check).

• This may seem a bit confusing at first, but it opens up many possibilities. Predicates are not limited to any “timescale”, but can use years, months, days and even hours, minutes or seconds (if the correspondent attribute gives such precision). This allows creating predicates for any time frame, which can be useful not only for ages, but any date attribute considered in a use case.