Physical Logical Type Instance Data The XDI Graph Basics The XDI Universal Graph is the logical data model by which resources and their associated data are discovered, identified and accessed on the Dataweb. This does not imply anything about the native data schema or physical storage mechanism!! Any resource that can be associated with an XRI is a candidate for inclusion in the XDI Graph (although XDI does place some constraints on the structure of the XRI) The XDI Universal Graph is the logical data model by which resources and their associated data are discovered, identified and accessed on the Dataweb. This does not imply anything about the native data schema or physical storage mechanism!! Any resource that can be associated with an XRI is a candidate for inclusion in the XDI Graph (although XDI does place some constraints on the structure of the XRI)

Physical Logical Type Instance Data The XDI Graph Basics The proposed XDI Universal Schema stipulates that the XRI element identifying an XDI Resource be made up of a combination of 4 subelements: Physical Authority Logical Authority Type Instance The proposed XDI Universal Schema stipulates that the XRI element identifying an XDI Resource be made up of a combination of 4 subelements: Physical Authority Logical Authority Type Instance

Physical Logical Type Instance Data The XDI Graph Basics The first Graph Element is Resource Nodes. These are depicted as black circles. A Resource Node is any point in the XDI Graph that is the parent of either another Resource Node, a Link Node, or a Data Node. It can also contain a reference to another Resource Node. Resource Nodes serialize into Resource Elements in the XDI Universal Schema The first Graph Element is Resource Nodes. These are depicted as black circles. A Resource Node is any point in the XDI Graph that is the parent of either another Resource Node, a Link Node, or a Data Node. It can also contain a reference to another Resource Node. Resource Nodes serialize into Resource Elements in the XDI Universal Schema !!1010 Black lines depict authoritative relationships. Authoritative Relationships are arcs where the Child Node is wholly dependent for it’s existence on the Parent Node. If the parent is deleted the child is also deleted. (This is analogous to a UML Composition Relationship.) Black lines depict authoritative relationships. Authoritative Relationships are arcs where the Child Node is wholly dependent for it’s existence on the Parent Node. If the parent is deleted the child is also deleted. (This is analogous to a UML Composition Relationship.)

Physical Logical Type Instance Data The XDI Graph Basics !!1010 Resource Nodes at any level MUST have ONLY ONE authoritative parent at the level above. =andy + home Data Nodes are depicted in green and CANNOT have children. They are ‘Terminal Nodes’ XMLResource Nodes are also Terminal Nodes and are also depicted as green dots. Data Nodes are depicted in green and CANNOT have children. They are ‘Terminal Nodes’ XMLResource Nodes are also Terminal Nodes and are also depicted as green dots. It is important to note that ‘labels’ (XRIs) actually name the arcs (lines) between nodes not the nodes themselves. Space permitting I always try to place the labels as close as I can to the arrow head of an arc.

Physical Logical Type Instance Data The XDI Graph Basics !!1010 =andy + work In this example the ooTao contact is delegated to Andy’s work so if Andy’s work changes, ooTao’s contact will still be up to date. Someone executing an XDI_get() for ooTao’s contact wouldn’t NEED to know that there is a Ref involved as the path to the data could be expressed as: In this example the ooTao contact is delegated to Andy’s work so if Andy’s work changes, ooTao’s contact will still be up to date. Someone executing an XDI_get() for ooTao’s contact wouldn’t NEED to know that there is a Ref involved as the path to the data could be expressed contact + A red dotted line shows a Reference (Ref). A Ref is a non- authoritative relationship. It is a way of saying.. “My value is the same as another node at this level. Whatever he says goes”. It denotes equivalence. The blue dotted line is a Backref. A Backref is the mechanism by which a node knows (or shows) that it is referenced. A red dotted line shows a Reference (Ref). A Ref is a non- authoritative relationship. It is a way of saying.. “My value is the same as another node at this level. Whatever he says goes”. It denotes equivalence. The blue dotted line is a Backref. A Backref is the mechanism by which a node knows (or shows) that it is referenced.

Physical Logical Type Instance Data The XDI Graph Basics contact NOTE: Because a Ref denotes equivalence it can ONLY go horizontally, i.e., across a level of the graph. These NOTES in red will show up from time to time. These are statements that we believe to be ‘Theorems’ about the XDI Graph ( and should therefore be imposed by the Schema whereever possible). I highlight them as we are actively looking for the exceptions that will disprove the rule. These NOTES in red will show up from time to time. These are statements that we believe to be ‘Theorems’ about the XDI Graph ( and should therefore be imposed by the Schema whereever possible). I highlight them as we are actively looking for the exceptions that will disprove the rule. !!1010 =andy + contact +

Physical Logical Type Instance Data The XDI Graph Basics The red dot is a Link Node. Links denote aggregation or inclusion. (This is analogous to a UML Aggregation Relationship.) A red dot is similar to the English language concept of ‘includes’; in this contact includes =Andy’s work , it can also include other values. One way to express the XRI of ooTao’s contact is therefore; The red dot is a Link Node. Links denote aggregation or inclusion. (This is analogous to a UML Aggregation Relationship.) A red dot is similar to the English language concept of ‘includes’; in this contact includes =Andy’s work , it can also include other values. One way to express the XRI of ooTao’s contact is therefore; !!1010 =Andy + +Contact =Andy/(+ )/work

Physical Logical Type Instance Data A’s Paths to C: xri://=A*B/C You may alternately use the =B synonym: xri://=A*(=B)/C A’s Paths to C: xri://=A*B/C You may alternately use the =B synonym: xri://=A*(=B)/C =B Delegation Syntax XRI delegation syntax (* or !) is used when one authority wants to provide a link to data at another authority… It looks like C is coming from =A (has a path rooted in =A), but C comes from B. =A !!1011 !!1012 C B, =B =B Resources representing Physical Authority nodes – the “root” of each instance of an XDI graph – can be linked just like any other level. In this case the Refs shown are links from a global registry representing the XRI 2.0 global context symbol (GCS) “!”. This registry has assigned the i-numbers “!1012” and “!1011” to these two Physical Authorities, so the absolute XRI paths are “!!1012” and “!!1011”.

Physical Logical Type Instance Data Versioning Syntax !!1010 =Andy + Primary $v/1 $v/2 Versioning Syntax is a form of delegation that can occur at any level. It represents an XRI cross-reference to the type “$v” (for version), followed by a version instance. !1 !2

Physical Logical Type Instance Data Virtual Nodes !!1010 =Andy + Primary $v/1 $v/2 We propose that XDI supports some special ‘Virtual Node’ syntax; one example of the ‘Virtual Node’ syntax is the $Current system word. This is an addressable node at the Version level that signifies ‘get the latest version’. This is a virtual node because there does not actually need to be any node named $Current. For example; xri://=Andy/(+ )/Primary/($Current) should return the $v/2 node. We propose that XDI supports some special ‘Virtual Node’ syntax; one example of the ‘Virtual Node’ syntax is the $Current system word. This is an addressable node at the Version level that signifies ‘get the latest version’. This is a virtual node because there does not actually need to be any node named $Current. For example; xri://=Andy/(+ )/Primary/($Current) should return the $v/2 node. !1 !2

Physical Logical Type Instance Data Building the Dataweb To start building any “tree” (instance) of the XDI graph “forest” (Dataweb), you first need a Physical Authority on which to root it. This Resource Node represents the network endpoint through which other nodes on the graph are addressable. Like any XDI Resource, it may have multiple XRI synonyms. This Physical Authority represents an i-broker addressable both via an abstract global independent XRI (!!1010) and via two concrete URIs based on DNS domain names. A Physical Authority could be any network-addressable endpoint, from a server farm to a cell phone to a thermostat. The Dataweb abstracts all Physical Authorities as peers, just like all IP addresses are peers. To start building any “tree” (instance) of the XDI graph “forest” (Dataweb), you first need a Physical Authority on which to root it. This Resource Node represents the network endpoint through which other nodes on the graph are addressable. Like any XDI Resource, it may have multiple XRI synonyms. This Physical Authority represents an i-broker addressable both via an abstract global independent XRI (!!1010) and via two concrete URIs based on DNS domain names. A Physical Authority could be any network-addressable endpoint, from a server farm to a cell phone to a thermostat. The Dataweb abstracts all Physical Authorities as peers, just like all IP addresses are !!1010,

Physical Logical Type Instance Data Building the Dataweb A Physical Authority registers and hosts Logical Authorities (similar to the way a PC can have multiple Users). A Logical Authority can in turn register other Logical Authorities. Note that while the i-number “!A2B3” for the second Logical Authority above is assigned by the Physical Authority !!1010, the i-name “andy” is assigned by the Logical Authority Thus there are now 3 XRI paths to this new Resource Node: xri://!!1010/!A2B3 A Physical Authority registers and hosts Logical Authorities (similar to the way a PC can have multiple Users). A Logical Authority can in turn register other Logical Authorities. Note that while the i-number “!A2B3” for the second Logical Authority above is assigned by the Physical Authority !!1010, the i-name “andy” is assigned by the Logical Authority Thus there are now 3 XRI paths to this new Resource Node: xri://!!1010/!A2B3 @ooTao !!1010 andy

Physical Logical Type Instance Data Building the Dataweb Here authority has resources that are about ooTao. It has delegated authority for Andy and Steven’s data to other (local) Logical !!1010 andy steven +Phone Support Admin + Work + +Phone Cell Primary

Physical Logical Type Instance Data Building the Dataweb If Steven now registers a global i- name, =Steven, we simply add a synonym at the node. This synonym represents a reference from the Logical Authority represented by the “=” !!1010 andy steven +Phone Admin + Work + +Phone Cell Primary !A2B4 =Steven

Physical Logical Type Instance Data Link Contracts !!1010 =Steven + Home One of the primary goals of XDI is to provide CONTROLLED access to data. The mechanism for control is establishing ‘Link Contracts’ between logical authorities that define ‘rules of engagement’. In order to make data accessible via an XDI Service one must create Link Contract Templates. Link Contracts are used to establish “Rights Paths” to data. NOTE: Any Logical Authority can only respond to requests on data (get, set, etc…) on Nodes under it’s own authority. The establishment of a ‘Rights Path’ is the process of establishing a XRI from one Logical Authority Node to a section of the XDI graph under another Logical Authority via an association node. If Steven only had his one piece of data, what might his Link Contract Template look like?... (next slide) One of the primary goals of XDI is to provide CONTROLLED access to data. The mechanism for control is establishing ‘Link Contracts’ between logical authorities that define ‘rules of engagement’. In order to make data accessible via an XDI Service one must create Link Contract Templates. Link Contracts are used to establish “Rights Paths” to data. NOTE: Any Logical Authority can only respond to requests on data (get, set, etc…) on Nodes under it’s own authority. The establishment of a ‘Rights Path’ is the process of establishing a XRI from one Logical Authority Node to a section of the XDI graph under another Logical Authority via an association node. If Steven only had his one piece of data, what might his Link Contract Template look like?... (next slide)

Physical Logical Type Instance Data Link Contracts !!1010 =Steven + $Contracts The first step in establishing a Link Contract Template is creating a permission path to the data. In this example the Private contract permissions an XDI Get path to =Stevens Home via =Steven’s Personal Dataset. This example is a little simplistic as it doesn’t have any versioning syntax. See the next slide to see a more realistic version of what a Contract Template might look like. The first step in establishing a Link Contract Template is creating a permission path to the data. In this example the Private contract permissions an XDI Get path to =Stevens Home via =Steven’s Personal Dataset. This example is a little simplistic as it doesn’t have any versioning syntax. See the next slide to see a more realistic version of what a Contract Template might look like. Home $Dataset Personal $Get Private TODO: Somewhere there should be a $Policies node that can be linked into the contract that stipulates the policies governing the sharing of this data. Home

Physical Logical Type Instance Data Link Contracts !!1010 =Steven + $Contracts This graph section is setup so that the Personal Dataset and the Private Contract can both be independently versioned. Home $Dataset Personal $Get $v/1 Private $v/2 $Set $v/1 $Get Here version 1 of the Private Contract permissions Get on the Personal Dataset and version 2 permissions both Get and Set on the same dataset. In this example $Get is repeated in both versions of the contract, so we theorize that there may be ‘delta’ syntax that would let v2 reference v1 and specify only the differences between them. Here version 1 of the Private Contract permissions Get on the Personal Dataset and version 2 permissions both Get and Set on the same dataset. In this example $Get is repeated in both versions of the contract, so we theorize that there may be ‘delta’ syntax that would let v2 reference v1 and specify only the differences between them. Home

Physical Logical Type Instance Data Link Contracts !!1010 =Steven + $Contracts Home $DataSet Personal $Get Private =Andy + Work In order to show ‘permissioning’ we need another Logical Authority to ‘permission’ I am intentionally showing a case where both entities are at the same Physical Authority so we don’t (yet) have to deal with replication across Physical Authorities. In order to show ‘permissioning’ we need another Logical Authority to ‘permission’ I am intentionally showing a case where both entities are at the same Physical Authority so we don’t (yet) have to deal with replication across Physical Authorities. In order to save space and simply illustrate the concepts I have gone back to the simple, non-versioned, depiction of the Link Contract Template.

Physical Logical Type Instance Data Link Contracts !!1010 =Steven + $Contracts Home $Dataset Personal $Get Private =Andy + Work $Assoc =Andy By adding the $Assoc (association) node we are saying that =Steven has a relationship with =Andy. The link between the =Steven/($Assoc)/(=Andy) node and the =Steven/($Contracts)/Private node establishes the contract instance that specifies the permissions. Now =Andy CAN access =Stevens data but hasn’t yet. By adding the $Assoc (association) node we are saying that =Steven has a relationship with =Andy. The link between the =Steven/($Assoc)/(=Andy) node and the =Steven/($Contracts)/Private node establishes the contract instance that specifies the permissions. Now =Andy CAN access =Stevens data but hasn’t yet.

Physical Logical Type Instance Data Link Contracts !!1010 =Steven + $Contracts Home $Dataset Personal $Get Private =Andy + Work $Assoc =Andy $Sig =Andy Signed copy of the contract $Assoc (=Steven/($Assoc)/(=Andy)) When =Andy agrees to the contract, =Andy’s digital signature of the contract is captured within =Stevens graph and =Andy creates an association node that completes the creation of the Rights Path.

Physical Logical Type Instance Data Link Contracts !!1010 =Steven + $Contracts Home $Dataset Personal $Get Private =Andy + Work $Assoc =Andy $Sig =Andy Signed copy of the contract $Assoc (=Steven/$Assoc)/(=Andy)) The Rights path explicitly states the privileges to the Data Node (# 1 from Andy’s perspective and #2 from =Steven’s perspective) 1) xri://=Andy/($Assoc)/((=Steven/$Assoc/(=Andy))*($Contracts/Private))*($Get)*(=Steven/(+ )/Home)) 2) xri://=Steven/$Assoc/(=Andy)*($Contracts/Private)*($Get)*(=Steven/(+ )/Home)) The Rights path explicitly states the privileges to the Data Node (# 1 from Andy’s perspective and #2 from =Steven’s perspective) 1) xri://=Andy/($Assoc)/((=Steven/$Assoc/(=Andy))*($Contracts/Private))*($Get)*(=Steven/(+ )/Home)) 2) xri://=Steven/$Assoc/(=Andy)*($Contracts/Private)*($Get)*(=Steven/(+ )/Home)) $Contract/Private =Steven/(+ )/Home

Physical Logical Type Instance Data TO DO: The Following slides are place holders for functional areas that we still need to consider in depth. I consider these headings future sections that may each be several slides in length.

Physical Logical Type Instance Data Link Contracts – More Complex Example The Biz Card contract permissions an Entity to Get ‘Support Phone’ and ‘Work ’. What would I do if I want to permission the Admin contract to Get the same 2 thing AND Set ‘Work ’? Option 1) Have 3 Links from Admin/($V/1), one that Refs each of the permission nodes. You could then link an $Assoc node to just that contract. Option 2) Have 1 Link under Admin/($V/1) that permissions Set for the ‘Work ’ node. You would then need to link an $Assoc node to BOTH contract to provide all the permission. Option 3) Have 1 Link under Admin/($V/1) that permissions Set for the ‘Work ’ node and add a Link at the Instance level from the Admin contract to the Biz Card contract. You could then link an $Assoc node to just the Admin contract to get all the permissions. The Biz Card contract permissions an Entity to Get ‘Support Phone’ and ‘Work ’. What would I do if I want to permission the Admin contract to Get the same 2 thing AND Set ‘Work ’? Option 1) Have 3 Links from Admin/($V/1), one that Refs each of the permission nodes. You could then link an $Assoc node to just that contract. Option 2) Have 1 Link under Admin/($V/1) that permissions Set for the ‘Work ’ node. You would then need to link an $Assoc node to BOTH contract to provide all the permission. Option 3) Have 1 Link under Admin/($V/1) that permissions Set for the ‘Work ’ node and add a Link at the Instance level from the Admin contract to the Biz Card contract. You could then link an $Assoc node to just the Admin contract to get all the permissions.

Physical Logical Type Instance Data Link Contracts – Permissioning a Community

Physical Logical Type Instance Data Resolving Synonyms – Unifying the Graph

Physical Logical Type Instance Data Removing a path - $Deleted?

Physical Logical Type Instance Data Delta Syntax - $Include and $Exclude?

Physical Logical Type Instance Data Questions: Is, and if so how, authentication expressed in the XDI Graph? Should +Type words (Dictionary Words) be constrained to Singular or Plural, and if yes, which? Should Instance words be Upper or Lower case? (Convention? Rule? Who Cares?) Should $Invitations be part of the XDI Protocol or should it be delegated to the application layer? Is, and if so how, authentication expressed in the XDI Graph? Should +Type words (Dictionary Words) be constrained to Singular or Plural, and if yes, which? Should Instance words be Upper or Lower case? (Convention? Rule? Who Cares?) Should $Invitations be part of the XDI Protocol or should it be delegated to the application layer?