XDI TC: Preparatory questions for tomorrow's XDI Policy Discussion

[Dan Blum <dan@respectnetwork.net>]

In preparation for Friday June 6 XDI TC meeting, I’ve uploaded my latest draft of XDI Policy here. In it, I’ve rewritten the introductory sections for clarity but am still struggling with the XDI syntax definitions and with not knowing all the (apparently) unwritten assumptions.

 

I am trying to fully document link contract establishment using Markus's walk through of Respect Connect XDI messages to try and reverse engineer a better understanding. The following is what I wrote (minus unfinished examples)

 

“A successful link contract establishment involves the following steps:

 1)     Requesting authority (RA) sends an XDI message identifying itself to the AA and providing a link contract template (from itself or a TA) describing the requested access.

2)     Authorizing authority (AA) determines request can be granted and generates a link contract instance granting the requested access, adds it to its graph, and returns an XDI message with the requested data to the RA

3)     AA algorithmically generates the address and ID of the RA’s governor link contract corresponding to the LC template from Step 1. AA sends a second XDI message (authorized by the governor LC) requesting to add the address of the LC instance from Step 2 to the RA’s graph.

4)     RA writes the address of the AA’s link contract instance to its graph”

 

Note: Step 4 as described above matches what the walkthrough says. But I Andy thinks that Step 4 should read “RA retrieves (or has?) the link contract and copies it and (optionally?) the requested data to the AA’s subgraph under an inner root of its own graph.”

 

My biggests question on which much else hinges is:

Are steps 1-3 described correctly?

In step 3 and 4, after the AA determines it can approve an access request, I think from the walkthrough that it sends an XDI message with the data and the address of the link contract to the RA. Assuming the RA wants to store the data, what patterns are assumed to occur, make sense, that I should describe?

 

1)    Should the RA just store the address of the link contract instance (LCI)? If so all it knows is that at one time it had an LC for the AA and it can try to directly request the data again without re-doing LC establishment.

2)    Should the RA store the full LCI without the data? If so, before sending any messages it can check to see if it might still have the specific required access. Also, how can I infer or does it need to be specified that the RA always has access to $get the full LCI after step 3?

3)    Should the RA only the LCI address with the data? The only point of this would seem to be if it was going to periodically check if LCI was still there, but not check the LCI every time it accessed the data.

4)    Should the RA store the full LCI and the data? This would allow it to make local access control checks all by itself. But how is it going to know if the LCI changes or is revoked? Does it have to check periodically? How often and where is that determined?

 

Other questions (in order of concern to me)

 

1)    Should we recommend adding / show example for a UTC time context to each LCI (for audit and exact referencing?

2)    The draft discusses a “public” LCI. Andy recommends it also discuss how a “public if authenticated” LCI would be created. Is that ok? If so, how does an AA check if a user is authenticated?

3)    What do the message patterns look like for an unsuccessful link contract establishment (LCE)?

4)    What does the link contract template look like for the request of a mix of mandatory and optional attributes? Assume such a pattern – would it cause the AA to generate an LCI that had some but not all of the requested attributes and that would be sufficient protocol or is more syntax and protocol needed for partial fulfillment?

5)    Where is the concept of an inner root described, so that I can reference it?

6)    Have we ever discussed policy inheritance with link contracts or does each link contract context override all contexts higher in the graph? There seems to be an implicit policy inheritance coming down from the root link contract. While inheritance may not be important for distributed peer to peer use cases, if XDI is used in more centralized access models inheritance may be desirable.

7)    Is the $do$extension specified somewhere? What should it say? Examples?

8)    The text on $matches mentions regular expressions. How can other kinds of matching (e.g. phonetic) in different languages be supported?

9)    The text on $greater or $lesser mentions numerical examples. How can other kinds of ordinalities (e.g. older, newer) be supported?

10) Markus asks - do we really need collection patterns for link contract templates, governors, instances? Why?