Skip to main content
Jump to: navigation, search

Relying Party Security Policy

Scenario

Consider the following scenario where a relying party requires a requester (user) to provide some information about her in order to access a service (resource). This involves the following steps:

  1. The user requesting a resource from the relying party.
  2. Relying party making available to the user a request describing what information (requested assertions) the user needs to provide in order to get access to the resource. The assertion request will be derived from the access control policy of the relying party (in the simplest case the assertion request and the access control policy will be identical maybe except for being described in different languages).
  3. The user matches the assertion request with the set of assertions (endorsed assertions) about her that are endorsed by some party (including herself in case of self signed statements) and making a selection which (set of) assertion(s) to send to the relying party.
  4. The user sending the relying party the selected assertion(s) plus supportive evidence (disclosed assertions).
  5. The relying party receiving the assertion(s) and supportive evidence, checking the correctness of the evidence w.r.t. the assertions, and matching the provided assertion with access control policy.

Scope of this Wikipage

The scenario motivates languages for expressing the following:

  • (Access control) policies
  • Assertion (claim) request language
  • Assertion (claim) language
  • Endorsed assertion language

This wikipage is dedicated to these languages needed to express the assertion request, the endorsed assertion, and the assertion. The evidence depends on the assertion mechanisms being used, e.g., X.509 or private credential systems such as idemix. Finally, this page deals with the requirements for access control policies such as extentions to XACML to leverage the privacy features of the assertion language.

The language aspects we are discussing on this wikipage is currently focused on authentication. We only cover the claim-related aspects of the languages and do not address issues like how to specify supported protocols, required encryption mechanisms... Those issues are addressed by specifications in the WS-* area.

An assertion request, an endorsed assertion, and an assertion are very similar, that's why we are subsuming them when discussing the language requirements.

Some Simple Examples

Here a couple of examples that the different language shall express (don't bother with the syntax in these examples, their purpose is to set the stage for further discussions.):

  • Access Control Policy Rules
    • older than 21 (endorsed by US driver's license)
    • username and password (endorsed by eclipse.org)
    • holder of passport (endorsed by US government) OR holder of passport (endorsed by Swiss government).
  • Requested Assertion:
    • older than 21 (endorsed by US driver's license)
    • username and password (endorsed by eclipse.org)
    • holder of passport (endorsed by US government) OR holder of passport (endorsed by Swiss government).
  • Endorsed Assertions:
    • (name=Mary Doe, address=exampleboulevard, city=nicetown, birthdate=1950-01-25) endorsed by Ohio MVA
    • (username=John, password=123E3y4) endorsed by eclipse.org
    • (name=Mary Doe, address=exampleboulevard, city=nicetown, birthdate=1950-01-25) endorsed by Swiss Government
  • Disclosed Assertions plus evidence:
    • older than 21 (endorsed by US driver's license), 98A8DF39D391234901A3D154BC...
    • holder of passport (endorsed by Swiss government), 978A78DF3D9D391234901A3D154BC...
    • holder of passport (endorsed by US government) OR holder of passport (endorsed by Swiss government), 243911128A8DF39D391234901A3D154BC...

Notes:

  • The part of the assertion not between parantheses is the actual attribute statement about entities (e.g., the requester), the part within parantheses specifies the evidence for the attribute statements.
  • The difference between the last two examples for disclosed assertions plus evidence is that the holder of passport (endorsed by Swiss government) + 978A78DF3D9D391234901A3D154BC... reveals that the user holds a US passport whereas holder of passport (endorsed by US government) OR holder of passport (endorsed by Swiss government) + 243911128A8DF39D391234901A3D154BC... only reveals that the user holds either a Swiss or a US passport, i.e., does not reveal which is the case.
  • The access control rules are so simple that they are equal to the assertion requests. This is not the case when more evolved access control features are used like relating subject expressions to object expressions.

Language Elements

More concretely, the assertion request, endorsed assertion, and assertion languages needs to have the following elements to be expressive enough for privacy-enhancing identity management: The statement part of the assertion contains:

  • Logical connectives between predicates, i.e., logical AND and OR
  • n-ary predicates over variables and constants
    • Variables can refer to either of the following
      • Attributes with evidence references
      • Encrypted data (a variable always refers to the corresponding plaintext)
      • Cryptographic commitments (a variable always refers to the value being committed)
    • Constants can, for example, be:
      • Integers
      • Strings
      • Date
    • Operators
      • Arithmetic operators: +, -, *, %
      • Comparison operators: >, =>, <, =<, =, not=

The evidence part of the assertion contains:

  • Evidence specification
    • Evidence

Notes:

  • Attributes and operators are specified using elements from appropriate namespaces, e.g., URIs like http://higgins.eclipse.org/privacy-ontology/age for referring to the age attribute of the requester.
  • Depending on the data type of a variable, different operators can be applied:
    • Integers: all arithmetic and comparison operators may be used
    • Strings: No arithmetic operators and only the = and not= comparison operators may be used
  • An assertion is typically accompanied by cryptographic evidence (e.g., an idemix proof)


Abstract Syntax and Semantics

Example

The following example formalizes an example policy, deliberately in abstract syntax in order to focus on the non-syntactic aspects of the language. We note that a concrete syntax could, for example, be RDF in N3 or XML or a specific XML language, orextensions to existing specifications. Either would be appropriate to model the conceptual digraph structure of the language as needed for expressing semantics for different attributes requiring the same evidence being referenced (e.g., the same instance of a SwissPassport idemix certificate).

Notes:

  • The XML-entity-like construct &higgins; is an abbreviation for "http://higgins.eclipse.org/privacy-ontology/" and is expanded whenever used. We use this mainly for better readability in the example.
  • Note that reference to "x" is a reference to an element with Label "x", much like a reference in XML. By this, the structure can model a directed graph.
  • To keep things simple, we use only one namespace.
Assertion
  Connective: Type = "&higgins;and"
    Predicate: Type = "&higgins;greater-than"
      Attribute: Name = "&higgins;age", Evidence = reference to "&higgins;SwissPassport"
      Constant: Value = "21"
    Predicate: Type = "&higgins;less-than"
      Attribute: Name = "&higgins;age", Evidence = reference to "&higgins;SwissPassport"
      Constant: Value = "30"
    Predicate: &higgins;equals
      Attribute: Type = "&higgins;name", Evidence = reference to "&higgins;SwissPassport"
      Constant: Value = "Doe"
    Predicate: Type = "&higgins;greater-than"
      Operator: Type = Type = "&higgins;add"
        Attribute: Name = "&higgins;bankBalanceUSD", Evidence = reference to "&higgins;BankStatement1"
        Attribute: Name = "&higgins;bankBalanceUSD", Evidence = reference to "&higgins;BankStatement2"
      Constant: Value = "120000"

EvidenceSpecification
  Evidence
    Label = "&higgins;SwissPassport"
    Type = "&higgins;idemix-private-certificate"
    CertificateType = "&higgins;SwissPassport"
    Issuer = "Swiss Government"
  Evidence
    Label = "&higgins;BankStatement1"
    Type = "&higgins;idemix-private-certificate"
    CertificateType = "&higgins;BankStatement"
    Issuer = "&higgins;Company-X"
  Evidence
    Label = "&higgins;BankStatement2"
    Type = "&higgins;idemix-private-certificate"
    CertificateType = "&higgins;BankStatement"
    Issuer = "&higgins;Company-Y"

The above assertion states that the age of the requester is greater than 21 and less than 30, endorsed by a SwissPassport certificate, that her name is "Doe" endorsed by the same SwissPassport certificate, and that the sum of the two bank statements from Company X and Company Y she holds is greater than 120000. Here, the bank statements are different by definition as they are from different issuers. In case one wants to enforce that two certificates of the same type and from the same issuer be different ones, this can be explicitly stated as a predicate by, e.g., stating non-equality of their serial numbers.

Semantics

The assertion part is a formula in propositional logics with predicates, but without the negation operator. This immediately defines the semantics of the logical operators. The variables refer to attributes (as contained in certificates of the requester), certificates, pseudonyms, plaintext corresponding to encryptions, and the values of cryptographic commitments. Variables have furthermore an evidence reference term attached that specifies a reference to an evidence element in the evidence part of the assertion. An evidence element states what cryptographic method to be used for endorsing the statement and who may vouch for this statement (e.g., who may be idemix certificate issuers). The actual cryptographic evidence is separate from the assertion and must fulfill the evidence specification. The construction of evidence references allows for one evidence element being used as evidence for multiple variables. For example, this allows that the same SwissPassport in the example be required as evidence for both the age statements and name statement. Note that the semantics is that the passport must be the same instance and cannot be two different SwissPassport certificates.

The language disentangles claims in terms of data types from the underlying evidence used to prove these claims. This allows for high expressivity in terms of trust management while retaining simplicity of the language.

If not stated otherwise, attributes apply to the requester. In case, for example, in a delegation scenario, we want to be able to make statements about the delegatee (e.g., age > 18 to prove legal ability to be a delegatee) and attributes about the delegater. This is not yet captured in the above example.

The Relation Between Access Control Policies, Assertion Requests, Endorsed Assertions, and Assertions

An assertion language is very similar to an assertion request language. Differences are that in the assertion request, values of attributes and other objects can be requested while in the assertion language these attributes would be instantiated with their value. Furthermore, the assertion language would have the evidence instantiated while it can be stated in a more abstract manner in the assertion request language. An assertion can be accompanied by (cryptographic) evidence, such as an idemix proof of endorsement.

An endorsed assertion language is typically the simplest among all as it only needs to express attributes and attribute metadata. An endorsed assertion is associated with, e.g., an idemix private certificate.

Noteable differences between an access control language and an assertion request language are:

  • An access control language is designed to relate attribute information known about a user to constants and to values of objects access to which is being controlled and express further conditions, also unrelated to attribute information itself, such as the time in which access is allowed.
  • An assertion request language is only concerned about requesting attribute information about a subject or subjects.

Thus, using rules of an access control language for requesting attributes from a subject may result in undesired release of rules that should remain secret as more than just the query for attributes is revealed to the requester.

Research has come up with access control languages that generate an assertion request from the access control rules thereby enforcing rule privacy of the relying party. A notable example for this is the work of Bonatti and Samarati (2002).

Architecture

Generalizing the ideas of Bonatti and Samarati accordingly leads to an architecture that separates the aspects of access control and assertion request. Such an architecture would have an access control system in place that would feature any policy language suitable for the purposes at hand. Whenever the access control rules are evaluated with respect to the requester's request, the evaluation leads to an assertion request. This assertion request is stated in an assertion request language that is sufficiently expressive.

Using this architectural idea leads to a flexible system in terms of being able to transparently replace the access control system while retaining the overall processing machinery on the requester side for processing the claim request. Only a lightweight mapping layer has to be constructed featuring the following:

  • Mapping access control rules to assertion requests;
  • Mapping assertions to an attribute information representation that is understood by the access control system.

The Access Control Policy Evaluation Engine

An identity system like Higgins requires a powerful access control policy evaluation engine when it comes to fully leveraging the power of the Higgins-featured identity provisioning methods such as idemix.

Currently deployed access control systems typically work as follows:

  1. Attribute information is solicited from the requester before the policy evaluation is done;
  2. The access control policy is evaluated based on the attroibute information obtained in Step 1;
  3. Access is granted or denied based on the decision computed in Step 2.

Such a system architecture has substantial drawbacks:

  1. In order for this to work, use attributes have to be solicited independently of the access control policy. This means, the policy semantics is in some way replicated.
  2. It is hard to construct a full-fledged trust negotiation architecture based on this approach;
  3. Privacy suffers in that typically more information is required from the requester than being required by the policy. For example, when the policy requires requester.age > 21, the requester's age will be solicited and then this value being checked for being > 21 during the policy evaluation.
  4. Current architectures do not allow for claims that contain logic OR operators such as the requester has a SwissPassport certificate OR the requester has a USAPassport certificate

For Higgins we think of an architecture for access control that has the following features:

  1. No attribute information is required from the requester ahead of the policy evaluation. That is, initially, a requester is always unknown to the relying party.
  2. Whenever the requester accesses a resource of a relying party, the access control policy evaluation engine evaluates the access control policy to determine what attribute information is required in order to make an access control decision. This information is made available to the requester in terms of a claim request.
  3. Claims that the requester provides for satisfying the claim request are provided to the access control engine and the access control policy is re-evaluated based on this obtained knowledge.
  4. The policy evaluation engine can process claims that are logical formulas containing OR connectives. OR statements help further reducing the amount of information being provided to the relying party.


An access control architecture of the above type has the following advantages:

  • Data minimization, that is, to request precisely the attribute information being required by the access control policy. This allows to obtain a system that better protects privacy of the requester by not obtaining excessive attribute information.
  • Easy maintainability and consistency: There is no need to replicate policy semantics within policies and for soliciting attribute information ahead of policy evaluation.
  • The simple approach of just placing a claim request as a policy into a web page that is to be access protected is covered as well assumed that the claim request serves as policy that is directly evaluated agains the claim from the requester.

Considering the above discussions, current access control systsms have the following further restrictions:

  • Provided attributes are limited to one subject's attributes; can't express delegation
  • Evaluation semantics: we can have different variables of the same data type, for example from different certificates and make different statements about them
  • Existing languages are confined to having only one attribute for each type
  • Attribute name and evidence together define a variable

TODO Items

  • Concrete syntax and semantics
  • Pseudonyms
  • Specifying the entity to which a statement applies, in particular allowing one formula to make statements about different parties (this is necessary in aq delegation relationship where statements about the delegatee and delegater can be required)
    • Requester
    • Delegater
    • Delegatee
    • User with ID 576145984389 (in a B2B transaction)
  • Data handling policy
  • Encryptions and commitments
    • Decryption condition

See Also

Back to the top