Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Relying Party Security Policy"

m
m
Line 29: Line 29:
 
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.
 
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.
  
Note: &higgins; is an abbreviation for "http://higgins.eclipse.org/privacy-ontology/" and is expanded whenever used to yield the proper URIs.
 
  
 
 
Note:
 
&higgins; is an abbreviation for "http://higgins.eclipse.org/privacy-ontology/" and is expanded whenever used to yield the proper URIs.
 
 
Assertion
 
  Connective: Type = "&higgins;and"
 
    Predicate: Type = "&higgins;greater-than"
 
      Attribute: Name = "&higgins;age", Evidence = reference to "SwissPassport"
 
      Constant: Value = "21"
 
    Predicate: &higgins;equals
 
      Attribute: Type = "&higgins;name", Evidence = reference to "SwissPassport"
 
      Constant: Value = "Doe"
 
    Predicate: Type = "&higgins;greater-than"
 
      Operator: Type = Type = "&higgins;add"
 
        Attribute: Name = "&higgins;yearlyIncomeUSD", Evidence = reference to "IncomeStatement1"
 
        Attribute: Name = "&higgins;yearlyIncomeUSD", Evidence = reference to "IncomeStatement2"
 
      Constant: Value = "120000"
 
 
EvidenceSpecifications
 
  Evidence
 
    Label = "SwissPassport"
 
    Type = "&higgins;idemix-private-certificate"
 
    CertificateType = "SwissPassport"
 
    Issuer = "Swiss Government"
 
  Evidence
 
    Label = "IncomeStatement1"
 
    Type = "&higgins;idemix-private-certificate"
 
    CertificateType = "IncomeStatement"
 
    Issuer = "Company X"
 
  Evidence
 
    Label = "IncomeStatement2"
 
    Type = "&higgins;idemix-private-certificate"
 
    CertificateType = "IncomeStatement"
 
    Issuer = "Company Y"
 
  
 
The above assertion states that the age of the requester is greater than 21, endorsed by a SwissPassport certificate, that her name is "Doe", and that the sum of the yearly income attribute of two income statements she holds is greater than 120000. Here, the income statements are different by definition as they are from different issuers. In case one wants to enforce that two certificates be different ones, this can be explicitly stated as a predicate.
 
The above assertion states that the age of the requester is greater than 21, endorsed by a SwissPassport certificate, that her name is "Doe", and that the sum of the yearly income attribute of two income statements she holds is greater than 120000. Here, the income statements are different by definition as they are from different issuers. In case one wants to enforce that two certificates be different ones, this can be explicitly stated as a predicate.

Revision as of 12:01, 25 October 2006

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 an 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, veryfing the correctness of the evidence w.r.t. the assertions, and matching the provided assertion with access control policy.

This page is dedicated to the languages needed to express the assertion request, the base 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.

Here a couple of examples that the different language shall express (don't bother with the syntax in these examples..):

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

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


The above assertion states that the age of the requester is greater than 21, endorsed by a SwissPassport certificate, that her name is "Doe", and that the sum of the yearly income attribute of two income statements she holds is greater than 120000. Here, the income statements are different by definition as they are from different issuers. In case one wants to enforce that two certificates be different ones, this can be explicitly stated as a predicate.

Note that the reference to "x" element refers to an element with Label "x". By this, the structure can model a directed graph needed for expressing semantics for different predicates requiring the same evidence (e.g., the same instance of a SwissPassport).

An assertion request and an assertion are very similar. Noteable differences are: - An assertion can be accompanied by (cryptographic) evidence - An assertion request can contain requests for attribute values, an assertion has those instantiated with the actual attribute value


The language needs to have the following elements:

  • logical connectives, i.e., AND and OR
  • n-ary predicates over variables and constants
    • the constants comprising: integers, strings, (iso-encoded) datum,..
    • variables: attributes (see below for definition), encrypted data, cryptographic commitments.
    • operations: +, -, *, %, >, =>, <, =<,
  • attributes are specified by URIs, e.g., higgins.eclipse.org/privacy-attributes/age

Each of the elements

  • meta information
    • 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)



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

Back to the top