1. Table of Contents: 1.XChange Log 2.XGraph Basics 3.XSpecial Forms in the XDI Graph 6.XDataweb Example 7.XLink Contracts 8.XContract Exchange Process 9.XLinking and Embedding 10.X Permissioning a Community 11.X Resolving Synonyms – Unifying the Graph 12.X Removing a path - $Deleted? 13.X Delta Syntax - $Include and $Exclude? 14.X $word Usage 15.X+word Usage 16.XUniversal Schema Representations 20.XQuestions

2. Authority Type Instance Data 1.1 Changes: DocumentVersion/DateSlide AffectedNew, Revised, Deleted Summary of Change (Primary Author) Change Request V 0.27.5,7.6RAdded Link from =Andy/$assoc/=Steven and named it $link (AD) V 0.28.xNCaching (AD) V0.27.9NIntroduce $public instance of $Contract V0.22.8NLogically split the levels. V0.24.2DRemoved Virtual Node slide. I now consider $current to be explicit. (There may be other virtual nodes later… $parent, ??) V0.27.2RChanged $Dataset to +Dataset. This really is an App construct not a global one. Any app can call it’s grouping mechanism whatever it wants, it is still a valid target for a $op Ref. V0.27.6RRemoved the $sig branch of the tree, preferring to put the signature as data in the $assoc branch instead. Seems cleaner to me. V0.27.7R Tried to correct the xris… again V0.28.XNStarted step by step evaluation of contract exchange. V0.214.XNDescription and example of different $words V0.27.8NInfinite recursion

3. Authority Type Instance Data 1.2 Changes: DocumentVersion/DateSlide AffectedNew, Revised, Deleted Summary of Change (Primary Author) Change Request V 0.320.1RUpdated answers to old questions (AD) V 0.37.10NInvalid Access (this would be bad) V 0.316.XNRepresentations of the Universal Schema V 0.32.5RUpdated definition of Ref V 0.3

4. Authority Type Instance Data 2.1 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)

5. Authority Type Instance Data 2.2 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

6. Authority Type Instance Data 2.3 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.)

7. Authority Type Instance Data 2.4 The XDI Graph Basics Resource Nodes at any level MUST have ONLY ONE authoritative parent at the level above. =andy +Email home ad@ootao.com 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.

8. Authority Type Instance Data 2.5 The XDI Graph Basics =andy +phone home 510-456-7878 @ooTao*andy contact +email ad@ootao.com A red dotted line shows a Reference (Ref). A Ref is a non-authoritative relationship. It is a way of saying.. “The graph at the references target is a sub-section of my graph”. It denotes a union. 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.. “The graph at the references target is a sub-section of my graph”. It denotes a union. The blue dotted line is a Backref. A Backref is the mechanism by which a node knows (or shows) that it is referenced. +phone work 510-445-5124 This implies that an XDI_get() on @ootao*andy would return one phone number and one email address. An XDI_get() on =andy would return 2 phone numbers and an email address. Q: How are we going to resolve collisions? Proposal: We use the value at the Source node of the ref. This implies that an XDI_get() on @ootao*andy would return one phone number and one email address. An XDI_get() on =andy would return 2 phone numbers and an email address. Q: How are we going to resolve collisions? Proposal: We use the value at the Source node of the ref.

9. Authority Type Instance Data 2.6 The XDI Graph Basics 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 wherever 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 wherever possible). I highlight them as we are actively looking for the exceptions that will disprove the rule. =andy +Email work ad@ootao.com @ooTao contact +Email

10. Authority Type Instance Data 2.7 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 example @ooTao’s contact email includes =Andy’s work email, it can also include other values. One way to express the XRI of ooTao’s contact email is therefore; xri://@ooTao/(+Contact)/email*(=Andy/(+Email)/work) 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 example @ooTao’s contact email includes =Andy’s work email, it can also include other values. One way to express the XRI of ooTao’s contact email is therefore; xri://@ooTao/(+Contact)/email*(=Andy/(+Email)/work) =Andy +Email work ad@ootao.com @ooTao email +Contact =Andy/(+Email)/work

11. Authority Type Instance Data 2.8 The XDI Graph Basics =Andy +Email work ad@ootao.com @ooTao email +Contact =Andy/(+Email)/work Andy =Andy/(+Email)/work @ooTao*Andy You can actually imagine that each level is split into 2 sub-levels. The top sub-level is for Resources and the lower is for Links. Drawn this way, a Black Line, an Authoritative Relationship should always traverse down either 1 or 2 levels. You can actually imagine that each level is split into 2 sub-levels. The top sub-level is for Resources and the lower is for Links. Drawn this way, a Black Line, an Authoritative Relationship should always traverse down either 1 or 2 levels. NOTE: A link MUST have a synonym that is equal to the XRI that is addressed by the Links Reference.

12. Authority 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 3.1 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 C B, =B (=B)

13. Authority Type Instance Data 3.2 Versioning Syntax =Andy +Email Primary $v/1 Ad@ooTao.com $v/2 Ad@convoii.net 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

14. Authority Type Instance Data 6.1 Building the Dataweb To start building any “tree” (instance) of the XDI graph “forest” (Dataweb), you simply need a place to root that graph. The authority may, or may not, be addressed by some other registry (global or P2P). To start building any “tree” (instance) of the XDI graph “forest” (Dataweb), you simply need a place to root that graph. The authority may, or may not, be addressed by some other registry (global or P2P). @ooTao !!1010, http://xdi.example.com, https://xdi.example.com

15. Authority Type Instance Data 6.2 Building the Dataweb Any Authority can register and host other Authorities. @ooTao andy !A2B3, @ooTao*andy !A2B4, @ooTao*andy*mom mom

16. Authority Type Instance Data 6.3 Building the Dataweb Here the @ooTao authority has resources that are about ooTao. It has delegated authority for Andy and Steven’s data to other (local) Authorities. @ooTao andy steven +Phone Support Admin +Email Work +Email +Phone Cell Primary !A2B3, @ooTao*steven !A2B4, @ooTao*andy

17. Authority Type Instance Data 6.4 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 “=” registry. @ooTao andy steven +Phone Admin +Email Work +Email +Phone Cell Primary !A2B4 !A2B3, @ooTao*steven, =Steven

18. Authority Type Instance Data 7.1 Link Contracts =Steven +Email Home One of the primary goals of XDI is to provide CONTROLLED access to data. The mechanism for control is establishing ‘Link Contracts’ between 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 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 Authority Node to a section of the XDI graph under another 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 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 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 Authority Node to a section of the XDI graph under another Authority via an association node. If Steven only had his one piece of data, what might his Link Contract Template look like?... (next slide)

19. Authority Type Instance Data 7.2 Link Contracts =Steven +Email $contract 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 email 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 email 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

20. Authority Type Instance Data 7.3 Link Contracts =Steven +Email $contract 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

21. Authority Type Instance Data 7.4 Link Contracts =Steven +Email $contract Home +DataSet Personal $get Private =Andy +Email 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.

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

23. Authority Type Instance Data 7.6 Link Contracts =Steven +Email $contract Home +Dataset Personal $get Private =Andy +Email Work $link =Andy =Andy Signed copy of the contract $link 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. $link =Steven

24. Authority Type Instance Data 7.7 Link Contracts =Steven +Email $contract Home +Dataset Personal $get Private =Andy +Email Work $link =Andy =Andy Signed copy of the contract $link =Steven 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/($link)/=Steven*($link)*(=steven/($contract)/private))*($get)*(=Steven/(+Email)/Home) 2) xri://=Steven/($link)/=Andy*(=steven/($contract)/Private)*($get)*(=Steven/(+Email)/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/($link)/=Steven*($link)*(=steven/($contract)/private))*($get)*(=Steven/(+Email)/Home) 2) xri://=Steven/($link)/=Andy*(=steven/($contract)/Private)*($get)*(=Steven/(+Email)/Home)

25. Authority Type Instance Data 7.8 Link Contracts – Reciprocal Relationships =Steven +Email $contract Home +Dataset Personal $get Private =Andy +Email Work $link =Andy =Andy Signed copy of the contract $link =Steven NOTE: Links to Resources that have Links back is valid in the XDI Graph it is incumbent on Apps that are navigating the graph to avoid infinite recursion. $contract +Dataset Personal $get Private =Steven Signed copy of the contract $link

26. Authority Type Instance Data 7.9 Link Contracts – The $public $contract =Steven +Email $contract Home +Dataset Personal $set Private =Andy +Email Work $link =Andy =Andy Signed copy of the contract $link =Steven The $public instance of a $Contract type is a special Contract Template. It establishes an Anonymous access path to a determined set of data. The $public contract does not require an $link to be valid. This is different from a ‘Public’ contract that permissions everyone; The ‘Public’ contract will still require authentication and an $link to provide valid access. The $public instance of a $Contract type is a special Contract Template. It establishes an Anonymous access path to a determined set of data. The $public contract does not require an $link to be valid. This is different from a ‘Public’ contract that permissions everyone; The ‘Public’ contract will still require authentication and an $link to provide valid access. $public $get

27. Authority Type Instance Data 7.10 Link Contracts – INVALID ACCESS!! NOTE: One logical authority CANNOT provide a rights path directly into another logical authorities data. Access MUST be mediated via a valid contract at the logical authority that ‘owns’ the data. See next slide for valid access delegation NOTE: One logical authority CANNOT provide a rights path directly into another logical authorities data. Access MUST be mediated via a valid contract at the logical authority that ‘owns’ the data. See next slide for valid access delegation description $instance $type validation $logical $type Description of how +email should be interpreted when used at the Instance level Description of how +email should be interpreted when used at the Type level $contract 1.0 revision $public $get

28. Authority Type Instance Data 7.10 Link Contracts –VALID ACCESS!! Here the wholesale pet company only provides access to their inventory to select vendors. But the Vendor makes the data publicly available via their catalog. +bird*sparrow $contract partners vendors $get $contract birds catalog $public @wholesale.pets +bird*love.bird @wholesale.pets @birds.online +currency*usd $link @birds.online +description common 15 25

29. 8.1 Link Contracts – Contract Exchange

30. Authority Type Instance Data 8.2 Link Contracts – Contract Exchange =Steven $contract +Dataset Personal $get Private =Andy +Email Work $link =Andy XDI_Get() XDI Doc … How do we represent an Error Code in the response to an xdi request?

31. Authority Type Instance Data 9.1 Linking and Embedding =Steven $contract +Dataset Personal $get Private =Andy +Email Work $link =Andy =Andy Signed copy of the contract $link =Steven Navigating across a $link node at the Instance level signifies crossing an authority boundary and is the equivalent of Linking in a compound document architecture.

32. Authority Type Instance Data 9.1 Linking and Embedding =Steven $contract +Dataset Personal $get Private =Andy +Email Work $link =Andy =Andy Signed copy of the contract Specifying a ref at the data level includes a complete section of a graph ….. IS THIS THING USEFULL AT ALL? Specifying a ref at the data level includes a complete section of a graph ….. IS THIS THING USEFULL AT ALL? +leads =steven

33. Authority Type Instance Data 10.1 Link Contracts – Permissioning a Community =Steven $contract +Dataset Personal $get Private $link =andy This instance of $link that is linked to a contract is providing unambiguous access to the data behind the linked $contract. It is permissioning =andy and only =andy. Over the next few slides we will explore how to permission groups and group members. This instance of $link that is linked to a contract is providing unambiguous access to the data behind the linked $contract. It is permissioning =andy and only =andy. Over the next few slides we will explore how to permission groups and group members. Permissions requests with SAML Assertion that requester is =andy

34. Authority Type Instance Data 10.1 Link Contracts – Permissioning a Community =Steven $contract +Dataset Personal $get Private $link @ootao Permissions requests with SAML Assertion that requester is @ootao

35. Authority Type Instance Data 10.1 Link Contracts – Permissioning a Community =Steven $contract +Dataset Personal $get Private $link @ootao* Permissions requests with SAML Assertion that requester has a name directly delegated from @ootao for example: @ootao*andy @ootao*steve @ootao*employees This does NOT provide access to @ootao, nor does is provide access to ‘descendant delegations’ like; @ootao*andy*brother @ootao*andy*rebecca @ootao*andy*wife*rebecca

36. Authority Type Instance Data 10.1 Link Contracts – Permissioning a Community =Steven $contract +Dataset Personal $get Private $link @ootao** Permissions requests with SAML Assertion that requester has a name delegated from @ootao at any level for example: @ootao*andy @ootao*steve @ootao*employees @ootao*andy*brother @andy*andy*rebecca @andy*andy*wife*rebecca This does NOT provide access to @ootao.

37. Authority Type Instance Data 11.1 Resolving Synonyms – Unifying the Graph

38. Authority Type Instance Data 12.1 Removing a path - $Deleted?

39. Authority Type Instance Data 13.1 Delta Syntax - $Include and $Exclude?

40. Authority Type Instance Data 14.1 $word Usage - Intro description $instance $type $policy validation $logical $type Description of how $policy should be interpreted when used at the Instance level Description of how $policy should be interpreted when used at the Type level All $words are themselves Logical Authorities and as such can all be found at the Logical level of the graph. The graph segment under a $word entry should contain the description and specification for the intended usage of that $word. The entire graph should be accessible via a $public contract. $contract 1.0 spec $public $get

41. Authority Type Instance Data 14.2 $word Usage - Intro description $instance $public Description of how $public should be interpreted when used at the Instance level Position: Instance level Resource Contains: 1.Contains $op-named Link Nodes that provide anonymous access to specified data. Versioning: No Code Use: When determining a requester’s access this node is included in addition to specifically permissioned data. Position: Instance level Resource Contains: 1.Contains $op-named Link Nodes that provide anonymous access to specified data. Versioning: No Code Use: When determining a requester’s access this node is included in addition to specifically permissioned data. First attempt at capturing $word usage specification.

42. Authority Type Instance Data 14.3 $word Usage - $contract Position: Type level Resource Contains: 1.A user-named node that has $op*-named Links that specify permissioning (required) 2.$public Instance Node (optional) Versioning: No Code Use: When a new Assoc is being established the code will traverse the $Contract children to find the portion of the graph that should be available to the requester. Position: Type level Resource Contains: 1.A user-named node that has $op*-named Links that specify permissioning (required) 2.$public Instance Node (optional) Versioning: No Code Use: When a new Assoc is being established the code will traverse the $Contract children to find the portion of the graph that should be available to the requester. $Contract $get $set $get Friends $public $Policy Std:23 $Policy

43. Authority Type Instance Data 14.4 $word Usage - $policy Position: Type level Resource Contains: 1.Instance node containing an XML Data Node representing the text that will be presented to an end user for acceptance and application readable instructions. (optional) 2.Instance node containing Links to other Instance Nodes that contain instructional information. Versioning: Yes Code Use: When a contracts are being negotiated $policy must be satisfied by either App Logic or human interaction. Position: Type level Resource Contains: 1.Instance node containing an XML Data Node representing the text that will be presented to an end user for acceptance and application readable instructions. (optional) 2.Instance node containing Links to other Instance Nodes that contain instructional information. Versioning: Yes Code Use: When a contracts are being negotiated $policy must be satisfied by either App Logic or human interaction. $Contract $get $set $get Friends $public $Policy Std:23 $Policy

44. Authority Type Instance Data 14.5 $word Usage - $RequireSignedRightsPaths Position: Instance level Resource Contains: 1.NA Versioning: na Code Use: Used as an alias on an Instance of a $policy node to specify that the exact permissions that are being granted must be signed as part of the contract. When this flag is set it means that any change in the permissioning matrix may invalidate the signed contract. Position: Instance level Resource Contains: 1.NA Versioning: na Code Use: Used as an alias on an Instance of a $policy node to specify that the exact permissions that are being granted must be signed as part of the contract. When this flag is set it means that any change in the permissioning matrix may invalidate the signed contract. $Contract $get $set $get Friends $public $Policy Std:23, $RequireSignedRightsPaths $Policy

45. Authority Type Instance Data 14.6 $word Usage - $link Position: Type level Resource Contains: 1.Instance nodes whose names match the URIs of Logical Authorities Containing: 1.$link Link Node that provides access to a graph segment under the named Logical Authority (optional) 2.Link nodes to one or more Instance Nodes of Type $Contract (optional) Versioning: No Code Use: The $link is used to find and validate the location of signed contracts and therefore confirm access to requested information. It can also be used to manage the local representation of another Logical Authority Position: Type level Resource Contains: 1.Instance nodes whose names match the URIs of Logical Authorities Containing: 1.$link Link Node that provides access to a graph segment under the named Logical Authority (optional) 2.Link nodes to one or more Instance Nodes of Type $Contract (optional) Versioning: No Code Use: The $link is used to find and validate the location of signed contracts and therefore confirm access to requested information. It can also be used to manage the local representation of another Logical Authority $link $contract Private =Andy $link

46. Authority Type Instance Data 14.7 $word Usage - $public Position: Instance level Resource Contains: 1.Contains $op-named Link Nodes that provide anonymous access to specified data. Versioning: No Code Use: When determining a requester’s access this node is included in addition to specifically permissioned data. Position: Instance level Resource Contains: 1.Contains $op-named Link Nodes that provide anonymous access to specified data. Versioning: No Code Use: When determining a requester’s access this node is included in addition to specifically permissioned data. $Contract $get $set $get Friends $public $Policy

47. Authority Type Instance Data 14.8 $word Usage - $link Position: Instance level Link (child of an instance of an $link) Contains: 1.Ref to an access node under another Logical Authority Versioning: No Code Use: Differentiates ‘My’ data about another Logical Authority from the data from that authority. Used to identify an authority boundary. Position: Instance level Link (child of an instance of an $link) Contains: 1.Ref to an access node under another Logical Authority Versioning: No Code Use: Differentiates ‘My’ data about another Logical Authority from the data from that authority. Used to identify an authority boundary. =Steven $link =Andy $link, =andy/($link)/(=steven)

48. Authority Type Instance Data 14.9 $word Usage - $v Position: ANY level Link Contains: 1.Ref to a resource that contains a versioned representation of the parent resource Versioning: No Code Use: Used to identify a versioning delegation and support version control logic such as automatically incrementing the version number to the next version number Position: ANY level Link Contains: 1.Ref to a resource that contains a versioned representation of the parent resource Versioning: No Code Use: Used to identify a versioning delegation and support version control logic such as automatically incrementing the version number to the next version number =Andy +Email Primary $v/1 Ad@ooTao.com $v/2 Ad@convoii.net !1 !2

49. Authority Type Instance Data 14.10 $word Usage - $current Position: ANY level Link Contains: 1.Ref to a resource that contains a versioned representation of the parent resource Versioning: No Code Use: Explicitly maintained by Apps this alias of a version link node is used to specify the graph representation that should be used when multiple versions are available. Position: ANY level Link Contains: 1.Ref to a resource that contains a versioned representation of the parent resource Versioning: No Code Use: Explicitly maintained by Apps this alias of a version link node is used to specify the graph representation that should be used when multiple versions are available. =Andy +Email Primary $v/1 Ad@ooTao.com $current,$v/2 Ad@convoii.net !1 !2

50. Authority Type Instance Data 14.11 $word Usage - $exception Position: ANY level Link Contains: 1.Ref to a resource that contains a versioned representation of the parent resource Versioning: No Code Use: Explicitly maintained by Apps this alias of a version link node is used to show that a node is ‘soft deleted’. The $deleted can be used in the syntax - $deleted*2 replacing the $v in the xri and providing restoration information while de-activating the version path. Position: ANY level Link Contains: 1.Ref to a resource that contains a versioned representation of the parent resource Versioning: No Code Use: Explicitly maintained by Apps this alias of a version link node is used to show that a node is ‘soft deleted’. The $deleted can be used in the syntax - $deleted*2 replacing the $v in the xri and providing restoration information while de-activating the version path.

51. Authority Type Instance Data 14.12 $word Usage - $delete Position: ANY level Link Contains: 1.Ref to a resource that contains a versioned representation of the parent resource Versioning: No Code Use: Explicitly maintained by Apps this alias of a version link node is used to show that a node is ‘soft deleted’. The $deleted can be used in the syntax - $deleted*2 replacing the $v in the xri and providing restoration information while de-activating the version path. Position: ANY level Link Contains: 1.Ref to a resource that contains a versioned representation of the parent resource Versioning: No Code Use: Explicitly maintained by Apps this alias of a version link node is used to show that a node is ‘soft deleted’. The $deleted can be used in the syntax - $deleted*2 replacing the $v in the xri and providing restoration information while de-activating the version path. =Andy +Email Primary $delete/($v/1) Ad@ooTao.com $current,$v/2 Ad@convoii.net !1 !2

52. Authority Type Instance Data 14.13 $word Usage - $op*($XXXXX) Position: Instance level Link from an instance of a $contract type resource. Contains: 1.Ref to any resource that should be permissioned. Versioning: No Code Use: Used to validate the rights of the requester to act upon the specified resource. Position: Instance level Link from an instance of a $contract type resource. Contains: 1.Ref to any resource that should be permissioned. Versioning: No Code Use: Used to validate the rights of the requester to act upon the specified resource. $op*($get) $op*($set)*($add)*($resource) $op*($set)*($add)*($link) $op*($add)*($data) $op*($set)*($add)*($xri) $op*($set)*($add)*($ref) $op*($set)*($add)*($backref) $op*($set)*($delete)*($resource) $op*($set)*($delete)*($link) $op*($set)*($delete)*($data) $op*($set)*($delete)*($xri) $op*($set)*($delete)*($ref) $op*($set)*($delete)*($backref) $op*($set)*($replace)*($data) $op*($set)*($replace)*($xri) $op*($get) $op*($set)*($add)*($resource) $op*($set)*($add)*($link) $op*($add)*($data) $op*($set)*($add)*($xri) $op*($set)*($add)*($ref) $op*($set)*($add)*($backref) $op*($set)*($delete)*($resource) $op*($set)*($delete)*($link) $op*($set)*($delete)*($data) $op*($set)*($delete)*($xri) $op*($set)*($delete)*($ref) $op*($set)*($delete)*($backref) $op*($set)*($replace)*($data) $op*($set)*($replace)*($xri) =Steven +Dataset Personal $get $contract Private

53. Authority Type Instance Data 15.1 +word definitions description $instance $type validation $logical $type Description of how +email should be interpreted when used at the Instance level Description of how +email should be interpreted when used at the Type level $contract 1.0 revision $public $get @IDcommons $dictionary +email email.primary

54. Authority Type Instance Data 15.2 +word definitions +email $mask +US-EN $definition $validation A valid, native SMTP address $representation +UK-EN I say, lets have a cup of tea.

55. Authority Type Instance Data 15.3 +word definitions +email $mask *@*.??? $definition $validation "^[a-zA-Z][\w\.-]*[a-zA-Z0-9]@[a-zA-Z0-9][\w\.-]*[a-zA-Z0-9]\.[a-zA-Z][a-zA-Z\.]*[a-zA-Z]$" $representation simple verbose

56. Authority Type Instance Data 15.4 +word definitions +email $mask member $definition $validation $representation range

57. Authority Type Instance Data 15.5 +word definitions +email $mask $definition $validation $representation +US-UK +US-EN Email:

58. 16.1 Universal Schema

59. 16.2 Universal Schema

60. Authority Type Instance Data 17.1 Community Membership = Shorthand

61. Authority Type Instance Data 17.2 Community Membership @ooTao +Email contact +Phone main +members $contract members +dataset communitymembers $public This is a community that has no members that is ready to receive members.

62. Authority Type Instance Data 17.3 Community Membership @ooTao +Email contact +Phone main +members $contract members +dataset communitymembers $public barry $link +Dataset i-broker @ootao $contract primary +email

63. Authority Type Instance Data 20.1 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? See XRI normalization rules Should Instance words be Upper or Lower case? (Convention? Rule? Who Cares?) See XRI normalization rules 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? See XRI normalization rules Should Instance words be Upper or Lower case? (Convention? Rule? Who Cares?) See XRI normalization rules Should $Invitations be part of the XDI Protocol or should it be delegated to the application layer?

64. Authority Type Instance Data Scratch !!1010 @ooTao +Email $contract Home +Dataset Personal $get Private $link =barry He did bad things incident $d/01-01-2004 barry =barry email emergency email primary T&E $d/01-01-2004 Worked on IDC !A2B1 $link +Dataset Personal $get Private @ootao $contract