xdi graph patterns oasis xdi tc submission drummond reed 2012-02-06 this document contains...
TRANSCRIPT
1
XDI Graph PatternsOASIS XDI TC Submission
Drummond Reed2012-02-06
This document contains illustrations of basic XDI graph patterns:
1. I-names, i-numbers, and synonyms: XDI statements used to assert multiple XRIs for the same logical resource
2. Local graphs and XDI discovery: statements that enable the global XDI graph to be distributed, discovered, and navigated across multiple locations on the network
3. Social graphs: relationships between XDI authorities
4. Literal contexts and versioning: contexts that accept a single data value and can describe versioning of that value
5. Simple contexts and ordering: contexts that represent a one-dimensional array of literal contexts and can describe ordering and typing of those values
6. Complex contexts: contexts that represent a two-dimensional array of literal contexts, simple contexts, and other complex contexts
7. Personas and roles: complex contexts and relations that model contextual identity for individuals
8. Link contracts: contexts used for XDI authorization
9. Policy expression: a context with conditional logic for rules evaluation
10. Messages: XDI graphs used in the XDI protocol
2
XDI Graph Notation
Example
Context node: Represents any logical context (see next page)
Contextual arc: Uniquely identifies a root or context node
Relational arc: Non-uniquely links root or context nodes
Terminal node: Represents a leaf node containing data
Root node: Represents the root context of an XDI graph
Literal arc: Singleton arc that identifies a terminal node
contextual
contextual
contextual
root
“value”
contextualrelational
literal
relational
root
contextual
“value”literal
contextterminal
context
context
context
terminal
3
Node hierarchy
Node
Terminal Context Root
Literal Ordinal ComplexSimple
Terminal nodes are the leaf points of the graph – the ones containing the raw data
Root nodes are the starting points of the
full 3-dimensional XDI graph
Literal contexts are 0-dimensional name/value pairs
name value
Ordinal contexts are 0-dimensional order/reference pairs
order ref
Simple contexts are 1-dimensional arrays of literal and ordinal contexts
instance value
instance value
instance value
order ref
order ref
order ref
name
Complex contexts are 2-dimensional arrays of literal, simple, and complex contexts
Complexity
I-names, i-numbers, and synonyms
=!0999.a7b2.25fd.c609
!1
4
=abc
()
=abc
=!0999.a7b2.25fd.c609
=!0999.a7b2.25fd.c609!1
+garden
+pea-patch
=!0999.a7b2.25fd.c609+garden
=!0999.a7b2.25fd.c609+pea-patch
The top two i-names are synonyms for the bottom i-number
Every XDI node has exactly one XRI address. A canonical equivalence relationship between two XDI context nodes (i.e., that they represent the same logical resource) may be declared using a $is relational arc. The inverse relation is $is$is. When navigating the graph, an XDI processor is required to redirect to the target node of a $is relation before continuing.
(http://xdi.example.com/=!0999.a7b2.25fd.c609)
These XRI cross-references are logically equivalent addresses for the local root of this graph
(=!0999.a7b2.25fd.c609)$is$is
$is
$is$is
The XRI =abc, an i-name, is a synonym for the XRI =!0999.a7b2.25fd.c609, an i-number
$is$is
Local graphs and XDI discovery
5
()
The XDI global graph is a single logical graph of which subsets are distributed across multiple locations on the network (clients, servers, databases, etc.) Each subset, called a local graph, begins with a local root node, expressed as an empty XRI cross-reference, (). A local graph may include XDI statements about the locations of other local graphs. This enables XDI clients to perform XDI discovery: navigation of the global graph by making XDI queries across a chain of local graphs.
(=!0222.e3f2.76cb.904a)
(@!0111.db4a.e317.7a12)
“http://xdi.example/com/@!0111.db4a.e317.7a12”
!
“http://xdi.example/com/=!0222.e3f2.76cb.904a”
This local graph contains two other roots describing the URIs of two other local graphs
$uri
!
$uri
The $uri context is a property of a root
$is$is
“http://xdi.example/com/=!0111.7af3.65d5.8cb7”
!
$uri
(=!0111.7af3.65d5.8cb7)
The XDI authority for this local graph is asserted using a synonym
!1
!1
!1
6
Social graphs
=abc
(http://facebook.com)
=xyz
+teammate
=abc is a teammate of =xyz in a Seattle soccer context
=abc is best friends with =xyz
=abc is friends with =xyz in the Facebook context
=abc
=xyz
+seattle
+best+friend
=xyz
+friend
+soccer
=xyz
(http://facebook.com)
(http://facebook.com)=xyz
+seattle
+seattle+soccer
+seattle+soccer=xyz
Social graph expressed at the (=!1111) local graph, for which =abc is the authority
$is$is() (=!1111) (=!1111)
=!1111
$is
+seattle+soccer=!2222
=!2222
=!2222 $is
$is
=!2222 $is
=!1111
=!2222
(http://facebook.com)=xyz
(http://facebook.com)=!2222
XDI graphs can also express the relationships between XDI authorities in different contexts. This example illustrates the relationship between =abc (i-number =!1111) and =xyz (i-number =!2222) in a global context, in a Facebook context, and in a Seattle soccer context.
7
Literal contexts and versioning
=!1111
“33”
+age
!
“2010-10-10T11:12:13Z”!
$v
!1
“32”!
“2010-09-09T10:11:12Z”
$d
!2
Literal context +age
Literal value
Versioning subgraph
First version context
First version datestamp
Second version, which is also the current version
=!1111=!1111+age
=!1111+age$d
=!1111+age$v
=!1111+age$v!1
()
$is
$d
!
First version value
Datestamp subgraph
$v
=!1111+age$v!2
A literal context is the first order of complexity in an XDI graph: a context node that has a single literal arc to a terminal node. By definition a literal context has exactly one instance. However a literal context may contain other contexts describing it (subproperties). The diagram below illustrates two standard XDI subproperties: datestamping (also a literal context) and versioning (a complex context).
=!1111+age$v!1$d
=abc=abc
$is
8
Simple contexts and ordering
=abc
+tel
“+1.206.555.1111”!
=abc()
!1
!2
“+1.206.555.2222”!
*2
*1=!1111+tel
=!1111+tel!1
=!1111+tel!2
=!1111+tel!2$d$d
=!1111+tel!2$v$v
…=!1111+tel$v
$v
…
+home
+home+fax
+work
A simple context is the second order of complexity in an XDI graph: a context that represents a set of literal contexts of the same type and optionally ordinals expressing their order. Each instance in a simple context is a literal context. The example shown below is a phone number. Two instances are shown, =abc+tel!1 and =abc+tel!2. The i-numbers (!1 and !2) persistently identify each instance within the set. Ordinal contexts with i-names (*1 and *2) assert the unique order of these instances. Relational arcs describe the non-unique type of each instance, e.g., +home, +home+fax, and +work.
Literal context version subgraph – reflects changes to literal values only
Simple context version subgraph – represents changes to the simple context graph only
=!1111+tel$d$d
… …
$is
$is
=!1111+tel*2
=!1111+tel*1
Two ordinal contexts, =abc+tel*1 and =abc+tel*2, assert the order of the two phone number instances
=!1111
=!1111
$is
9
Complex contexts
+passport
!
!1
!2
=!1111+passport
=!1111+passport!1
$d
$v
…=!1111+passport$v
$v
…
+ca
+nz
A complex context is the third order of complexity in an XDI graph: a context that represents a set of literal contexts, simple contexts, and complex contexts. Each instance of a complex context is another complex context. The example shown below is a passport. Two instances are shown, =abc+passport!1 and =abc+passport!2. (Ordering of these instances is not shown in this diagram, but uses the same ordinal pattern as with simple contexts.)
Simple context version subgraph – reflects changes to the simple context graph only
Complex context version subgraph – represents changes to the complex context graph only
“2005-01-01T00:00:00Z”
“Canada”
“987654321”
“2010-10-01T00:00:00Z”
“New Zealand”
“123456789”
=!1111+passport$d
$d
……
!
!
!
!
!
+country
+num
+expires
=!1111+passport!1+country
+country
+num
$d
$v
…
Literal context version subgraph – reflects changes to the literal value only
…=!1111+passport!2$d$d
=!1111+passport!2$d$v
=!1111+passport!2+country
=!1111+passport!2
=abc=abc
()
=!1111
$is=!1111 $is
$is
+expires
10
Personas and roles
!1
!2
=!1111!1
+home
+work
Personas are an example of using complex contexts to model the identity of a person. In the example below, the person =!1111 (aka =abc) has two personas, =!1111!1 and =!1111!2. Each of these is an instance of =!1111. @!4444 (aka @example.co) is a company in which the =!1111!2 persona plays the role of president.
+president is a role that the persona =!1111!2 plays in the context of company @!4444
=!1111!2
=abc=abc
()
=!1111
$is
=!1111
$is
$is
“33”
+age
!
=!1111+age($)
@!4444
@!4444
@example.co
@example.co
$is+president
=!1111!1 and =!1111!2 are personas of =!1111 that enable =!1111 to control the sharing of portions of =!1111’s personal graph
The ($) variable relation allows graphs to be included in other graphs – in this case, the =!1111!2 persona includes =!1111+age
11
Link contracts (1)
This root link contract permits the XDI subjects to which it is assigned to perform all XDI operations on the local graph
A link contract is a complex context used for XDI authorization. A link contract is defined by a$do context. Shown below is the “bootstrap” link contract in a graph, called a root link contract: a $do child of the root node. The $all relation that points back to the root asserts that the assignee(s) of this contract have “root access”, i.e., permission perform all XDI operations on the entire local graph.
=!0999.a7b2.25fd.c609
=abc
()
=abc
=!0999.a7b2.25fd.c609
(=!0999.a7b2.25fd.c609)
$is
$is$is
$do$do
(=!0999.a7b2.25fd.c609)
$all
$is$do
$is$do is the relation used to explicitly assign the permissions of a link contract to one or more XDI subjects
12
Link contracts (2)
!1
!2
=!1111!1
+home
+work
This diagram shows the addition of a link contract to the Personas and Roles diagram shown earlier. This link contract, created by =!1111 to control access to his/her =!1111!2 persona, gives the organization @!4444 $get (read) permission on that persona.
=!1111!2
=abc=abc
()
=!1111
$is
=!1111
$is
$is
“33”
+age
!
=!1111+age($)
@!4444
@!4444
@example.co
@example.co
$is+president
This link contract gives the assignee(s) permission to do an XDI $get operaton on the =!1111!2 persona, i.e., read anything in its subgraph
$do
$get
$is$do
The $is$do relation assigns this link contract to @!4444, which means people from that company will be able to access the =!1111!2 persona
Policy expression
!2
$do
13
$if begins the policy expression branch of a link contract
$and branches group policy instances that must all evaluate to true
$not branches group policies that must evaluate to false
(=!1111)
$or branches group policies of which at least one must evaluate to true
=!1111
$is$is
$if
$and
$or
$not
“{policy}”!
!1
“{policy}”!
!1
“{policy}”!
!2
“{policy}”!
!1
Policy expression is handled by the $if branch of link contracts. The three policy contexts are $and (all policies must be satisfied), $or (at least one policy must be satisfied), and $not (all policies must not be satisfied).
Link contract
14
Messages
(=!2222)
$do
$get
$add
“to” XDIlocal graph
Message instance
Message operations
Message envelope
“2010-12-22T22:22:22Z”
$d
!1234
(=!2222)
=!1111
=!1111$msg
Message datestamp
Message context
()
$msg
=!1111
“from” XDI authority (sender)
=!1111$msg!1234
=!1111$msg!1234$d
=!1111$msg!1234$do
(=!1111)
$is$is“from” XDI local graph
=!2222
=!2222!1$do
!1
=!2222
(=!1111)
!
(!3)(=!1111)(!3)
XDI messages are XDI graphs sent from one XDI local graph (the “from” graph) to another local graph (the “to” graph) to perform an XDI operation (e.g., $get, $add, $mod, $del, $move, $copy). Every message must reference the link contract that authorizes the operation it is requesting. Note that the $add relation records the source graph for auditing purposes.
$get$do
$is()
Every message must include a $do reference to the link contract that authorizes the operation it is requesting, e.g., this message references the =!2222!1$do link contract for $get permission on the =!2222!1 persona
$do
$is$do
=!2222!1