1. Introduction

The trust policy language (TPL) is a language used to define groups and rules for becoming a group member. Rules are functions on certificate fields and to become a member in a group one has to present a certificate. Groups can represent roles and thus, a role based access control system can use the TP system to assign roles to a non predefined population. This situation is typical to e-business where the accessed population in not known in advance.

See Policy DTD for the exact syntax of the Policy.

The TPL syntax is written in XML. At the top level are groups and under each group are rules for group membership. Each rule has some inclusion statements to define the valid certificates that it should check and a function, which is implemented as a computation tree with conditions on certificate's fields.
 

Example  - A retailer who give discounts to preferred customers

The  policy below defines that a preferred customer is an employee of a department of a partner company. The policy defines a "partners" group whose members are set by certificates signed by the retailer. Then, there is a  "departments" group whose members are departments in one of the "partners" companies. A preferred customer (the "customers" group) is an employee of one of the departments.

<?xml version="1.0"?>
<POLICY>
     <GROUP NAME="self">
     </GROUP>

     <!---->
     <!-- preferred partners -->
     <!---->

     <GROUP NAME="partners">
          <RULE>
               <INCLUSION ID="partner" TYPE="partner" FROM="self" ></INCLUSION>
          </RULE>
     </GROUP>

     <!---->
     <!-- departments of my partners -->
     <!---->

     <GROUP NAME="departments">
          <RULE>
               <INCLUSION ID="partner" TYPE="partner" FROM="partners"></INCLUSION>
          </RULE>
     </GROUP>

     <!---->
     <!-- A preferred customer should have a certificate from a preferred company -->
     <!---->

     <GROUP NAME="customers">
          <RULE>
               <INCLUSION ID="customer" TYPE="employee" FROM="departments"></INCLUSION>
               <FUNCTION>
                    <GT>
                         <FIELD ID="customer" NAME="rank"></FIELD>
                         <CONST>3</CONST>
                    </GT>
               </FUNCTION>
          </RULE>
     </GROUP>

</POLICY>

2. The language release 1.0

The <POLICY> tag 
The <GROUP> tag 
The <RULE> tag 
The <INCLUSION> tag 
The <EXCLUSION> tag 
The <FUNCTION> tag 
The <AND>, <OR> tags 
The <NOT> tag 
The <EQ>, <NE>, <GT>, <GE>, <LT>, <LE> tags 
The <FIELD> tag 
The <CONST> tag 
 

2.1 The <POLICY> tag

This is the root node in the tree.

2.1.1 Attributes

none

2.1.2 Children

The  Groups that forms the policy.

2.2 The <GROUP> tag

A group is an entity that is used to group members where a member is represented by a public key. A group can be used as a role group in role based access control systems. A special group is the 'self' group, which includes the self public key.

2.2.1 Attributes

  1. NAME - the name of the group. This is a local name that only has meaning to the local site.

2.2.2 Children

  1.  RULE - a rule defining how to become a member in the group.

2.3 The <RULE> tag

A rule is a function on certificate's fields and it is used to determine group membership.

2.3.1 Attributes

none

2.3.2 Children

  1.  INCLUSION(s) - a filter on the set of certificates to consider when checking the rule validity
  2.  EXCLUSION(s) - a filter on the set of certificates that should not appear (negative certificates)
  3.  FUNCTION - the function to evaluate.

 

2.4 The <INCLUSION> tag

An Inclusion statement stands for "Exist a certificate X" such that the function holds. Note that the function refers to fields of certificate X.

2.4.1 Attributes

  1. ID - a unique ID which will be used in the function to refer to the certificate's fields. This is a local name used only in the scope of the RULE.
  2. TYPE - a filter on certificate type. Each certificate has a type field (implemented as an extension for X509v3 certificates).
  3. REPEAT - the different number of certificates from that type that should exist. default is 1. If REPEAT > 1 then any field reference to that ID in the function results in evaluating the field REPEAT number of times.
  4. FROM - name of a group. Only certificates signed by a member in that group are candidates to evaluate the function.

2.4.2 Children

none

2.5 The <EXCLUSION> tag

An exclusion statement stands for "Not Exist a certificate X" such that the function holds. The function refers to fields of certificate X. To make sure that "not exist a certificate X", all the possible certificates of that type should be checked.

2.5.1 Attributes

  1. ID - a unique ID which will be used in the function to refer to the certificate's fields. This is a local name used only in the scope of the RULE.
  2. TYPE - a filter on certificate type. Each certificate has a type field (implemented as an extension for X509v3 certificates).
  3. REPEAT - the different number of certificates from that type that should (not) exist. default is 1. If REPEAT > 1 then any field reference to that ID in the function results in evaluating the function REPEAT number of times.
  4. FROM - name of a group. Only certificates signed by a member in that group are candidates to evaluate the function.

2.5.2 Children

none

2.6 The <FUNCTION> tag

The function is a set of constraints on certificates fields. A function is built as a computation tree where internal nodes are logical operators (AND, OR, NOT) and relations (EQ, GT etc) and leaves are FIELDS and Constants . A certificate instance is a tuple of certificates (C1, ... Ck,Ck+1,...Cn) where k is the number of  INCLUSION tags and n-k is the number of  EXCLUSION tags in the  RULE  and certificate Ci passed the i'th INCLUSION filter. Evaluation of the function tree is done independently for each  certificate instance and the function is true if at least one instance satisfies the function.

2.6.1 Attributes

none

2.6.2 Children

Any operator or logical relation tag.

2.7 The <AND>, <OR> tags

A logical And/Or between two children.

2.7.1 Attributes

none

2.7.2 Children

Must have two children; each one is a logical operator and/or relation.
  

2.8 The <NOT> tag

A logical Not of a child.

2.8.1 Attributes

none

2.8.2 Children

Must have one child that is a logical operator and/or relation.

2.9 The <EQ>, <NE>, <GT>, <GE>, <LT>, <LE> tags

A relation between two children each one is a  Field and/or a Constant . The order of the children is important (i.e. <GT> is true if the first child is greater than the second child).

2.9.1 Attributes

none

2.9.2 Children

Two children each one is a  Field and/or a Constant .
  

2.10 The <FIELD> tag

The field tag is used to extract a value from a certificate.

2.10.1 Attributes

  1. ID - a unique id of the certificate where the field appear (see  INCLUSION ID).
  2. NAME - the name of the field in the certificate. In current implementation fields are X509 extensions and field names are statically (hard coded)  bound to OIDs. We are working on a way to dynamically map field names to OIDs such that field names are unique within certificate type.

2.10.2 Children

none
  

2.11 The <CONST> tag

A constant value.
 

2.11.1 Attributes

none

2.11.2 Children

A constant value.
 
3. Future extensions to the language
 
 
  1. Additional FROM tag flexible to allow for the intersection and union of groups (e.g., the policy can say that a certificate's issuer can come from group A or must be in groups B and C)
  2. Add a tree of RULES with logical operations at intermediate nodes and RULES in the leaves.