XDI Link Contract Deep Dive

Transcription

1 XDI Link Contract Deep Dive August 25-27, 2014 (Document by Dan Blum, slightly edited for Aug 29 XDI TC call by Markus) Introduction I learned that this is the second- or third XDI retreat, and for some reason they always occurred in August. Drummond note: I ve been working on XDI for a long time, its as if I was trying to solve a rubics cube that no one else is aware of, but that I believe will have great value when I finish it. Many of us certainly think so, and that s why we came to the Respect Network s new office is in Berkeley just across the railroad tracks near the bay. Our agenda was to explore the XDI models underlying link contracts, generate some tangible examples and suggestions for the spec, and deepend our understanding. These notes are a work in progress. I will keep cleaning them up, that is, replacing white board screen shots with computer-drawn diagrams. But soon they will be finished as a work-product and some of the learnings and content will move forward into other deliverables. Goals of meeting 1) 2) 3) 4) Advance understanding of XDI syntax Test consistency of syntax against the graph model Establish and document standard patterns and constructs Establish and document standard link contract patterns and constructs Dan described access control model as in XDI policy Contents Table of Contents Introduction... 1 Goals of meeting... 1 Contents... 1 Graph model... 2 Common root node... 2 More on absolute and relative identifiers...2 Authorities... 2 Graph display formats... 2 More on identifiers... 2 Entities and attributes... 2

2 Inverse statements... 2 Equivalence relations... 2 Security considerations... 2 Data modeling... 2 Link contract discussion... 2 Versioning... 2 Signatures and link contracts... 2 Building link contract examples... 2 Variables... 2 Usage policies, a new idea - $For branch...2 Graph Editor issues... 2 Discussion of XDI standards process...2 Making XDI display more documentation-friendly...2 More on the interaction between peer roots...2 Conclusion meeting results...2 Graph model Drummond drew the model formally known as GEAV graph entry- attributevalue recommends reading Wikipedia article on EA model GEAV Graph nodes (roots) -> entity nodes -> attribute nodes -> value nodes -> literal Graph root entities are called authorities Graph Root entities can contains other graphs or entities or attributes Entities can contain entities or attributes Attributes can contain attributes or values Values must contain a literal First four types of entries are context nodes, last is literal, value node exists to address the literal If there s no value node, value is undefined If there is a value node, and you have no literal node, the value is null You could say that with these containment rules XDI is infinitely contextual

3 Nodes connected by arcs: Three kinds of arcs in XDI contextual, relational and literal Common root node There is a logical common root node in XDI, drawn as a blank circle with no name, containing no data Although we see the graph as many peer root graphs in fact we may desire some consistency among contexts (e.g. names or attributes like =DANB or # ) in whatever graphs they appear; that s why we ve defined a common root for all XDI Discovery spec assumes this common root If all systems using XDI follow the specs you have can have absolute identifiers for the same thing wherever they occur in the graph; names defined in registries, semantic attributes in dictionaries can be consistent More on absolute and relative identifiers Every node is identified by the label on the line, or arc, pointing to it Every node has an address comprised of the arc of all the the nodes pointing to it in the graph Every node has an absolute or relative identifier In having absolute identifiers XDI is different from DNS or X.500 which don t; although DNS uses co or www as conventions In the example, =dan is an absolute identifier, but data about the entity appears in multiple graphs and statements about things like the height attribute can even disagree; however the graph remains consistent =dan<#height>&/&/ tall +xdi.org=dan =andy=dan#height&/&/ short However, if you want to NOT use the absolute names, you can use cross references to make them relative identifiers +nym=(dan) However, if it reads +nym=(mailto:dan.blum@gmail.com) the contents are no longer relative, they are absolute Authorities Each graph is controlled by an authority and there are three types of authorities

4 = person names + organization or legal names *Things Root types common root, peer roots (=danb) and inner roots (=danb/=a) (=b) means the graph whose identifier is =b If you discover this graph the expectation is that you ll be able to get to that entity s information Technically, the beginnings of all graphs look like the figure above; the cross ref represents =b asserting its ownership of the graph; the whois statement The inner root is a first class relation that initiates a subgraph to reify everything about that relationship Here are some examples of =a with various friend relationships and an inner root to reify all of the (=a/#f) and a specific relationships (=a/=c) If an inner root is copied to another graph, its contents and subcontexts must all be identical in each graph =a/#friend/=c =a has a friend =c (=a/#friend)//=c =a s friend =c By reifying the relationship this way we can make statements about it, associate metadata about the relationship

5 Question for TC: If a link contract template needs to ask for a piece of data that may be structured in different ways in different graphs (a home and work number in one, a collection in another) how do you pose your template, your get operations? Graph display formats All roots are drawn as open circles Context nodes that aren t roots are drawn as dark circles Contextual arcs are solid lines, relational arcs are dashed lines There are three types of entities and three types of attributes and variables - Singleton Collection Members These types, and the ordering of collections, are shown by the labelling of the arc with the [,],<,>,@,! symbols Attributes are drawn as dark diamonds Digression on addresses and implied statements (see figure below)

6 More on identifiers XDI schemes Extensible identifier formats that have been mapped into XDI, e.g.!:uuid: Three ways to identify members:!234!(crossref) e.g. #british, #american, #french,!:scheme:data Entities and attributes If an entity is an authority it is identified by its authority type, if it is not an authority it is identified by its class Entities and Attributes have classes - $ for reserved, # for general Attributes are displayed surrounded by chevrons to distinguish from entities

7 This figure illustrates implied statements Inverse statements -a//=b is a contextual statement and the inverse of that is =b/$is()/=a The ability to assert the inverse of a contextual statement is important for the XDI messaging spec

8 For example, =danb/$is()/+respectnetwork or +xdi.org or +university Would let me assert that I can be found in these other graphs; the figure below shows how I could be found either as a child node or as a root node at another XDI endpoint Equivalence relations $is identity, or union $ref - reference $rep replace

9 All three relationship types can have inverse relations, backpointers $rep and $ref nodes cannot contain any data, just the reference can only have one $ref or $rep going out per node have to reference only other nodes that are semantically equivalent, e.g. singleton to singleton, or singleton to member of collection XDI relational arcs don t extend XDI node addresses, one cannot generate node address containing relation Example of Andy s gamer tag =km below $is a union so it implies its inverse and its all me (strongest relationship), is especially strong when =a and =b have the same parent node in this case, the contents of each node must not conflict; however if =a and =b=a have conflicting context it is ok because they have different parent; one subgraph represents =a making statements about itself, the other represents =b making statements about =a; I ve read that a fundamental goal of semantic languages is to allow authorities to disagree on semantics without breaking the consistency and coherency of the whole graph under the common root $ref and $rep are unidirectional, $ref can be the only arc on a node, a server returns the $ref to the client (or it may resolve local refs only, or it may resolve a certain number of refs) $rep can be the only arc on a node, a server must traverse and get the data, logically merging it under the original graph, $rep doesn t appear in the results (=a/=a) is a root link contract shown in this picture below; these could enforce the ability for the authorities =a and =b and only them to control their graphs

10 Security considerations To make sure that although anyone can write a $ref to anything, the controls enabling access (or not) work as they should to maintain each authority s graph as theirs Question for TC: its unclear how the $ref should be processed, whether as a chained request or as referral to the client, the TC should specify this behavior (proposal server gives what it is has) Regarding the processing of $ref, we have discussed introducing an "operation parameter" called $deref, which would instruct the server to traverse them as if they were $rep To make XDI have a consistent and portable authorization model, XDI makes the following assumptions 1) There is a common root such that all the peer roots can be viewed as one graph, or as separate graphs; logically the common graph would be drawn the same way whether it was held in one XDI service provider or in many 2) The behavior of operations on the graph logically behave as if all the peer roots were separate authorities within the common graph 3) The XDI policy spec will model bootstrap link contracts and whois statements as necessary to support its design objectives: e.g., peer to peer and graph portability Data modeling Name / number pattern when data is persistent, not reassignable, we re encourage to use the uuid pattern with members of a collection so that it will not move between times it is accessed Still seeing questions about whether data should be represented as collection or singleton when you have only one value at present, but could have more later General guidance: if you are thinking about creating an attribute and it won t have a value, make it an entity

11 XDI dictionary spec needs to define schema definition process for community dictionaries to create attribute and entity definitions (e.g. <# > and #address) Link contract discussion Note for TC (editor): modify the policy doc to change incorrect public link contract controls entire graph sentence; global change the use of the word own to control Versioning Discussion of versions of templates Note: the $v needs to be extensible to the major/minor pattern, but you can do that through Note for TC: the XDI versioning spec may need to be put on the critical path, too complex to go in the dictionary Figure above shows the potential use of version with both the link contract template and the link contract instance Signatures and link contracts Good discussion about where link contract should be mandatorially signed and if so should part of it be unsigned meaning that the AA can make changes without revoking it Building link contract examples Breaking down the link contract inner root (like any other root) drawn under the common root Inner root reifies relationship, but doesn t have implied policy to impose control, have to state policy explicitly

12 Discussion on how XDI addresses are written and graphs drawn (with implied context) Thus you always have to include ( $do$if$true)$is{$from}/$is/=ra Could the TC decide this was implied and the default? Policy statements $do$if are expressed as nested inner roots under the inner root of the LCI Policy is true if $from is $RA because actual identifiers match, or if the equivalence statement exists in the graph Note for TC: need to define $valid, or to define that by default valid is always implied (e.g. in link contract template asks) Note: the reason we stick with the UUID even in the intuitive version is because we want to reinforce the practice of using persistence identifiers, which are ordered members of collections Variables Variables used for substitution of instances, such as the LC template creating an instance; in some cases an instance may contain a variable (such as authenticate sender of message at runtime ); in that case you have double curly braces; if just one level of variable you strip and instantiate, otherwise you just strip; this can be seen in the link contract example Usage policies, a new idea - $For branch With authorization service generating UI form from XDI link contract template under the covers

13 Note for TC: We ended up with quite a few suggested elaborations of the link contract format in the deep dive meeting that we need to update you on. Graph Editor Issues Issue: potential bug in the graph editor when it imports xdi, display 1, exports, imports, display 2 different (Andy will send example statements causing this) Issue: the graph editor is displaying attribute collections as solid circles rather than as solid diamonds Another bug in editor: LCI instance path wrong after $get Bugs in the graph editor may actually bugs in xdi.js, which is still experimental. Making XDI display more documentation-friendly Drummond said TC has or used to have an XDI nested display syntax Avoids need to restate absolute path on every line of a set of statement Like the ditto convention in the English language

14 Question for TC: should we start using the nested display syntax in some documentation? Should we use ## or something else for comments in documentation or regular display syntax? More on the interaction between peer roots The figure below captures a rich discussion we had. XDI is like a mesh network of peer root graphs. Although many graphs may be hosted by CSPs, and all graphs identifiers should be listed in a registry, peers can communicate directly if they know each other s URI. The notional common root enables the peer to peer behavior. Question for TC: Verify that the expected behavior for an endpoint is that it should follow equivalence relations within its own graph. Question for TC: what are the rules or guidelines for when and how endpoints should follow $refs or other equivalence relations into other graphs (where they may or may not have access but might want to try).

15 Conclusion meeting results We feel as if we re validating the graph model; none of the issues we discussed change it What the LC instances look like

16