($and/ <== DO NOT REMOVE - switch for preventing MathML interpretation of dollar signs on this page)

About

This proposal specifies the basic patterns for XDI link contracts, the portable authorization format that controls all data exchange in XDI.

Change Log

Terminology

Link contracts may be used to apply and enforce any type of policy over shared data and messages, including security, privacy, re-sharing, synchronization, and termination.

The parties to the establishment of a link contract are:

  1. Requesting authority: the XDI authority requesting data and permissions under a link contract.

  2. Authorizing authority: the XDI authority authorizing an instance of a link contract in order to grant permissions to data under its authority.

  3. Template authority: the XDI authority publishing a link contract template, which may or may not be the requesting authority or authorizing authority.

  4. Community authority: the XDI authority for a community link contract

There are three core link contract patterns used for different stages of defining an XDI authorization relationship.

  1. A link contract template is a link contract containing XDI variables that must be replaced by the authorizing authority in order to create a valid link contract instance. A link contract template may be published by any XDI authority, not just a requesting or authorizing authority. Templates provided by neutral third parties make it much easier for link contracts to be standardized, promoting interoperability of XDI vocabulary and permissions.

  2. A link contract instance is produced by replacing the variables in a link contract template.

  3. A requester link contract is a special link contract used by a requesting authority (RA) to govern acceptance of link contract instances conforming to a specific link contract template. The requester link contract expresses the policies enforced by a specific requesting authority for accepting instances of a specific link contract template to be written by an authorizing authority (AA) into the RA's own graph. The address of a requester link contract is algorithmically derived from the name of the AA, the name of the RA and the address of the link contract template on which it is based, providing a standard way to authorize acceptance of link contract instances based on a known template.

  4. A community contract is a link contract issued by a community authority that is stored in an AA's graph and used to authorize a link contract instantiation request ({$do} message) from an RA. All link contract requests must reference a valid community contract, which may state policies on allowable request originators, link contract templates or template authorities to be used, as well as specify rules for processing requests, such as enabling automated approval or required interactive human review.

Following is a high-level summary of the three link contract pattern types.

Singleton Patterns

SPECIFIC INSTANCE: (<--AA-->/<--RA-->)<--TA--><--ID-->$do/<--operation-->/<--AA--><--object-graph-->

GENERIC INSTANCE: (<--AA-->/<--class-->)<--TA--><--ID-->$do/<--operation-->/<--AA-->/<--class--><--AA--><--object-graph-->

COMMUNITY CONTRACT PATTERN: To be completed.

TEMPLATE PATTERN: <--TA--><--ID-->{$do}/<--operation-->/{$to}<--object-graph-->

REQUESTER PATTERN: (<--RA-->/<--TA--><--ID-->{$do})$do/$set{$do}/({$to}/<--RA-->)<--TA--><--ID-->$do

Collection Patterns

SPECIFIC INSTANCE: (<--AA-->/<--RA-->)<--TA--><--ID-->[$do]!<--member-id-->/<--operation-->/<--AA--><--object-graph-->

GENERIC INSTANCE: (<--AA-->/<--class-->)<--TA--><--ID-->[$do]!<--member-id-->/<--operation-->/(<--AA-->/<--class-->)<--AA--><--object-graph-->

TEMPLATE PATTERN: <--TA--><--ID-->{$do}!<--member-id--><--operation-->/{$to}<--object-graph-->

REQUESTER PATTERN: TBD

Where:

Notes about this overall architecture:

  1. The only difference between the singleton and collection patterns is whether the link contract node itself is an XDI entity singleton or entity collection.
  2. Both the instance and the requester patterns begin with an inner root so that they can have an algorithmically-generated address relative to an AA and RR that is always identical in both authorities’ graphs. `The template and the requester contain an XDI {$to} variable to refer to AA variables outside of the policy expression branch. The instance pattern does not include XDI variables because they have been instantiated in order to create the instance.
  3. In the instance pattern, each of the three components specializes the associated $word that follows it, i.e.:
  4. <--authorizing-authority--> specializes $to.

  5. <--requesting-authority--> specializes $from.

  6. <--template-authority--><--template-id--> specializes $do.

All link contract templates MUST consist of a set of XDI statements in one of the two following patterns:

Link Contract Template Singleton Pattern

<--TA--><--ID-->{$do}/<--operation-->/{$to}<--object-graph-->

<--TA--><--ID-->{$do}!<--member-id->>/<--operation-->/{$to}<--object-graph-->

The {$to} Variable

The {$to} variable represents the authorizing authority who will authorize a link contract instance. This is the same variable used to represent the receiver of an XDI message in XDI messaging.

  1. Each relational <--operation--> predicate in the $do or [$do]<--member-id--> context MUST define a permission granted by the link contract to an XDI message that satisfies the link contract policies.

  2. The <--object-graph--> of each <--operation--> predicate defines the XDI graph or subgraph over which the permission for the specified operation is granted.

A link contract MAY contain one or more $do$if or [$do]<--member-id-->$if statements. These are the policy expression branch of the link contract. They express the policies that an authorizing authority will apply to allow or deny XDI messages that claim to be authorized under the link contract. XDI policies can express any set of rules that can be captured using XDI policy expression syntax.

A meta link contract is used by a requesting authority to authorize acceptance of link contract instances based on a link contract template. IMPORTANT: the XDI address of the requester link contract is algorithmically composed by placing the XDI address of the link contract template under the inner root of the requesting authority followed by template authority context. This enables XDI clients to reference the requesterlink contract for authorization in an XDI $set{$do} message for a new link contract instance (see XDI messaging).

All meta link contracts except a root meta link contract (see below) MUST consist of a set of XDI statements in one of the two following patterns:

Requester Link Contract Singleton Pattern

(<--RA-->/<--TA--><--ID-->{$do})$do/$set{$do}/({$to}/<--RA-->)<--TA--><--ID-->$do

Requester Link Contract Collection Pattern

TBD

$set{$do} Operation

A requester link contract uses the $set{$do} operation that is used to authorize new link contract instances. The object of this predicate MUST be the XDI address of the link contract template for which it will authorize instances.

The XDI policy expression statements in a requester link contract expresses the requesting authority's policy for accepting instances of a specific link contract template. For example, these policy statements might require the authorizing authority to:

All link contract instances except a root link contract or public link contract (see below) MUST consist of a set of XDI statements in one of the two following patterns:

Link Contract Instance Singleton Pattern

(<--AA-->/<--RA-->)<--TA--><--ID-->$do/<--operation-->/<--AA--><--object-graph-->
(<--AA-->/<--RA-->)<--TA--><--ID-->$do$if<--boolean-context-->/<--operator-->/<--condition-->

Link Contract Instance Collection Pattern

(<--AA-->/<--RA-->)<--TA--><--ID-->[$do]!<--member-id-->/<--operation-->/<--AA--><--object-graph-->

Note that in link contract instances, all XDI variables have been replaced.

The root link contract is the bootstrap link contract that gives an XDI authority access to its own XDI subgraph.

  1. The root link contract is based on the generic link contract instance pattern, with the following constraints:
    1. The requesting authority is set to the XDI authority.
    2. The authorizing authority is set to the XDI authority.
    3. The template ID is empty.
    4. The root link contract MUST use the singleton pattern, i.e. there MUST only be one per XDI authority.
  2. The root link contract SHOULD grant $all permission to the XDI authority's subgraph.

  3. The root link contract SHOULD contain a policy that restricts the sender of an XDI message to the XDI authority's subgraph.
  4. Authentication SHOULD be required for access to a root link contract. However the XDI authority is the ultimate authority for the policies pertaining to any link contract.

Root Link Contract Pattern

(<--AA-->/<--AA-->)$do$all

The public link contract is the well-known link contract that an XDI authority can offer for access to the portion of its XDI subgraph (if any) that is publicly available.

  1. The public link contract is based on the generic link contract instance pattern, with the following constraints:
    1. The requesting authority is set to $anon.

    2. The authorizing authority is set to the XDI authority.
    3. The template ID is set to $public.

    4. The public link contract MUST use the singleton pattern, i.e. there MUST only be one per XDI authority.
  2. The public link contract SHOULD grant $get permission to the $public subgraph of the XDI authority's subgraph.

  3. In addition, the public link contract MAY grant permissions to other parts of the XDI authority's subgraph.
  4. The public link contract SHOULD NOT contain a policy.
  5. Authentication SHOULD NOT be required for access to a public link contract. However the XDI authority is the ultimate authority for the policies pertaining to any link contract.

Public Link Contract Pattern

(<--AA-->/$public)$public$do/$get/<--AA-->$public

LinkContractPattern (last edited 2014-12-01 08:35:11 by drummond-xns)