1 / 14

XDI Graph Patterns

This document contains illustrations of basic XDI graph patterns: I-names, i -numbers, and synonyms: XDI statements used to assert multiple XRIs for the same logical resource

marcel
Download Presentation

XDI Graph Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. This document contains illustrations of basic XDI graph patterns: I-names, i-numbers, and synonyms: XDI statements used to assert multiple XRIs for the same logical resource Local graphs and XDI discovery: statements that enable the global XDI graph to be distributed, discovered, and navigated across multiple locations on the network Social graphs: relationships between XDI authorities Literal contexts and versioning: contexts that accept a single data value and can describe versioning of that value Simple contexts and ordering: contexts that represent a one-dimensional array of literal contexts and can describe ordering and typing of those values Complex contexts: contexts that represent a two-dimensional array of literal contexts, simple contexts, and other complex contexts Personas and roles: complex contexts and relations that model contextual identity for individuals Link contracts: contexts used for XDI authorization Policy expression: a context with conditional logic for rules evaluation Messages: XDI graphs used in the XDI protocol XDI Graph Patterns OASIS XDI TC SubmissionDrummond Reed 2012-02-06

  2. XDI Graph Notation Root node: Represents the root context of an XDI graph Context node: Represents any logical context (see next page) Terminal node: Represents a leaf node containing data Contextual arc: Uniquely identifies a root or context node Relational arc: Non-uniquely links root or context nodes Literal arc: Singleton arc that identifies a terminal node Example root contextual root contextual context literal terminal contextual “value” context literal terminal contextual “value” context contextual relational context relational

  3. Node hierarchy Complexity Node Terminal Context Root 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 Ordinal Simple Complex Literal contexts are 0-dimensional name/value pairs Ordinal contexts are 0-dimensional order/reference pairs Simple contexts are 1-dimensional arrays of literal and ordinal contexts Complex contexts are 2-dimensional arrays of literal, simple, and complex contexts value ref name name order value instance value instance value instance ref order ref order ref order

  4. I-names, i-numbers, and synonyms 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) () $is$is These XRI cross-references are logically equivalent addresses for the local root of this graph (=!0999.a7b2.25fd.c609) $is$is =abc =abc The XRI =abc, an i-name, is a synonym for the XRI =!0999.a7b2.25fd.c609, an i-number =!0999.a7b2.25fd.c609 $is =!0999.a7b2.25fd.c609 +pea-patch =!0999.a7b2.25fd.c609+pea-patch +garden =!0999.a7b2.25fd.c609+garden The top two i-names are synonyms for the bottom i-number $is $is !1 =!0999.a7b2.25fd.c609!1

  5. Local graphs and XDI discovery 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. () The XDI authority for this local graph is asserted using a synonym $is$is (=!0111.7af3.65d5.8cb7) $uri The $uri context is a property of a root !1 (@!0111.db4a.e317.7a12) ! “http://xdi.example/com/=!0111.7af3.65d5.8cb7” $uri This local graph contains two other roots describing the URIs of two other local graphs (=!0222.e3f2.76cb.904a) !1 ! $uri “http://xdi.example/com/@!0111.db4a.e317.7a12” !1 ! “http://xdi.example/com/=!0222.e3f2.76cb.904a”

  6. Social graphs 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. $is$is () (=!1111) (=!1111) Social graph expressed at the (=!1111) local graph, for which =abc is the authority =abc =abc (http://facebook.com)=xyz $is =!1111 =!1111 =abc is best friends with =xyz =xyz =xyz +best+friend $is =!2222 =!2222 (http://facebook.com) (http://facebook.com) =abc is friends with =xyz in the Facebook context (http://facebook.com)=xyz =xyz $is =!2222 +friend (http://facebook.com)=!2222 +seattle =abc is a teammate of =xyz in a Seattle soccer context +seattle +soccer +seattle+soccer =xyz +seattle+soccer=xyz $is =!2222 +teammate +seattle+soccer=!2222

  7. Literal contexts and versioning 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). () =abc =abc $is =!1111 +age =!1111 =!1111+age Literal context +age ! “33” Literal value $is $d Datestamp subgraph =!1111+age$d ! “2010-10-10T11:12:13Z” $v Versioning subgraph =!1111+age$v !2 !1 =!1111+age$v!1 =!1111+age$v!2 First version context ! $v “32” First version value Second version, which is also the current version $d =!1111+age$v!1$d First version datestamp ! “2010-09-09T10:11:12Z”

  8. Simple contexts and ordering 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. () =abc =abc +home+fax “+1.206.555.1111” =!1111 +home ! $is =!1111+tel!1 !1 $is Two ordinal contexts, =abc+tel*1 and =abc+tel*2, assert the order of the two phone number instances *2 +tel =!1111 =!1111+tel*2 =!1111+tel*1 =!1111+tel *1 $is !2 =!1111+tel!2 +work ! “+1.206.555.2222” $d $d =!1111+tel!2$d =!1111+tel$d … … $v $v =!1111+tel!2$v =!1111+tel$v … … Simple context version subgraph – represents changes to the simple context graph only Literal context version subgraph – reflects changes to literal values only

  9. Complex contexts 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.) () =abc =!1111+passport!1+country =abc +country ! =!1111 =!1111+passport!1 +num “Canada” $is ! !1 “987654321” =!1111 $is +ca +passport +expires ! “2005-01-01T00:00:00Z” =!1111+passport =!1111+passport!2+country +nz +country $is ! !2 +num “New Zealand” ! =!1111+passport!2 “123456789” ! +expires “2010-10-01T00:00:00Z” $d $d $d =!1111+passport$d =!1111+passport!2$d$d … … … $v $v $v =!1111+passport$v =!1111+passport!2$d$v … … … Simple context version subgraph – reflects changes to the simple context graph only Literal context version subgraph – reflects changes to the literal value only Complex context version subgraph – represents changes to the complex context graph only

  10. Personas and roles 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. () =abc =abc =!1111!1 $is !1 =!1111!1 and =!1111!2 are personas of =!1111 that enable =!1111 to control the sharing of portions of =!1111’s personal graph $is =!1111 +home =!1111 +work $is !2 The ($) variable relation allows graphs to be included in other graphs – in this case, the =!1111!2 persona includes =!1111+age =!1111!2 +age ($) =!1111+age @example.co ! “33” @example.co $is +president @!4444 +president is a role that the persona =!1111!2 plays in the context of company @!4444 @!4444

  11. Link contracts (1) 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) () (=!0999.a7b2.25fd.c609) $is$is =abc =abc =!0999.a7b2.25fd.c609 $is =!0999.a7b2.25fd.c609 $all $do $do $is$do $is$do is the relation used to explicitly assign the permissions of a link contract to one or more XDI subjects This root link contract permits the XDI subjects to which it is assigned to perform all XDI operations on the local graph

  12. Link contracts (2) 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. () =abc =abc 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 =!1111!1 $is !1 $is =!1111 +home =!1111 +work $get $is !2 $do =!1111!2 +age ($) =!1111+age ! “33” @example.co @example.co $is +president @!4444 $is$do @!4444 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

  13. Policy expression 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). $is$is (=!1111) =!1111 !2 $do Link contract $if begins the policy expression branch of a link contract $if $and $and branches group policy instances that must all evaluate to true !1 ! “{policy}” $or $or branches group policies of which at least one must evaluate to true !1 ! !2 “{policy}” $not ! “{policy}” !1 $not branches group policies that must evaluate to false ! “{policy}”

  14. Messages 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. $is$is “from” XDI local graph (=!1111) (!3) () (=!1111)(!3) (=!1111) “from” XDI authority (sender) =!1111 =!1111 $msg $add Message context =!1111$msg !1234 $is$do Message instance =!1111$msg!1234 $d Message datestamp (=!2222) =!1111$msg!1234$d $is() ! (=!2222) “2010-12-22T22:22:22Z” “to” XDIlocal graph Message envelope Message operations =!2222 $do =!2222 =!1111$msg!1234$do $get !1 $get 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 =!2222!1 $do =!2222!1$do

More Related