Difference between revisions of "Relying Party Security Policy"

Revision as of 14:27, 25 October 2006

Scenario

Consider the following scenario where a relying party requies a user to send some information about her. 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 asserion 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

This page is dedicated to the 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.

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.):

• 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.

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. Both 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).

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.

An assertion request, an endorsed assertion, and an assertion are very similar. Noteable differences are:

• An assertion can be accompanied by (cryptographic) evidence;
• An endorsed assertion has, e.g., an idemix private certificate associated;
• An assertion request can contain requests for attribute values, an assertion has those instantiated with the actual attribute value.

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), 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. This construction 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.

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.

Still To Do (Selection)

• 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

Language format: to be determined could be homegrown, use RDF so that it maps into data model. Similar language to request tokens from issuer. Also relates to WS-policy-constraints [1]

Elements that need to be expressed:

• type of i-card
• attribute
• issuer
• recipient
• in encrypted form (under what key)
• in committed form
• arbitrary statement over attributes (e.g., age < 18)
• logical formulas over terms (AND, OR)
• backing of statement (self-signed, passport checked, .....)
• data handling policy (privacy policy stating things like purpose,

retention time etc)

See Also

• Higgins Wiki