Re: [xdi] XDI TC: Preparatory questions for tomorrow's XDI Policy Discussion

["=Drummond Reed" <drummond.reed@xdi.org>]

Dan, thanks for sending this to set up the link contract discussion tomorrow. Since your message is chock-full of questions, I'll do my best to provide some answers inline that hopefully help guide discussion tomorrow. (However I suspect it will be hard to go much deeper than that in this thread given how complex some of the issues are.)

On Thu, Jun 5, 2014 at 6:05 PM, Dan Blum <dan@respectnetwork.net> wrote:

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.

In the Respect Connect scenario, I think of this initial XDI message being "pulled" into the AA's XDI endpoint by clicking a Respect Connect button. But you are correct that what starts the pattern is an XDI message from RA to AA that requests an LCI (link contract instance) by sending an LCT (link contract template).

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

Two notes on this:

1. I believe the AA returns an LCI to the RA (your step 3 below) before it returns any data. 
2. At this moment I can't remember what the mechanism was to include or not include the data. Myself, I believe that should be controlled by a statement in the LCT, as some RAs are going to want the data back with the LCI and some won't. 
   

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.

I think the AA is not just "adding the address" of the LCI to the RA's graph, but doing a $set of the LCI to the RA's graph, and using the address of the LCG (link contract governer) to authorize that $set message. 

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

Yes, I would put it this way: "RA verifies the AA's XDI message against the LCG, and if authorized, writes the LCI into its graph."

 

Note: Step 4 as described above matches what the walkthrough says. But 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.”

Sorry, I can't parse that sentence. If what you are saying is that the RA "pulls" a copy of the LCI from the AA after it receives the $set request for the LCI, that doesn't make sense to me. But this is something we should discuss on the call tomorrow.

 

My biggests question on which much else hinges is:

Are steps 1-3 described correctly?

Modulo my notes above, yes. But let's clarify on the call tomorrow. (IMHO the TC should produce sequence diagrams for the whole link contract initiation flow so it's crystal clear.)

 

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?

GREAT question, and one I think we should talk through on tomorrow's call. Among the options you describe below, our job is to decide if we should choose only one, and if not, how to specify each option clearly so developers are not confused and XDI endpoints know exactly how to process link contract negotiation. 

 

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.

This option certainly makes sense to me. 

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?

This option also makes sense, as does your question about it. 

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.

This option doesn't sound like it's worth the complexity. 

4)    Should the RA store the full LCI and the data? This would allow it to make local access control checks all by itself.

This option makes sense to me, and I suspect will be frequently used. 

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?

For that, I believe the LCT should specify whether the RA has a subscription ($copy) to the LCI. If so, the RA will be updated if the AA changes the LCI. Otherwise the RA should have $get permission on the LCI, so it can poll to determine changes. Alternately the RA can just request data under the LC as needed until it fails, then do a poll to determine the cause of the failure.

 

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?

I believe all LCTs, LCGs, and LCIs should have datestamps. 

2)    The draft discusses a “public” LCI. Andy recommends it also discuss how a “public if authenticated” LCI would be created. Is that ok?

 IMHO, a "public if authenticated" LCI is simply a public LCI with policy attached by the AA.

If so, how does an AA check if a user is authenticated?

By looking at the authentication policy in the public LCI.

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

Meta note: I suggest avoiding another LC abbreviation (which I'd like to reserve for just types of LCs). Rather let's just call this process "link contract negotiation" or "LC negotiation".

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?

Very good question. We have discussed this several times before over the past few years and now we simply need to make a decision as to how to add that metadata to the LCT. 

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

The official description is at http://xdi.org/xdi-spec-docbook/xdi/xdi-core-1.0/xdi-core-1.0-wd02.xml#idp1743780496

Markus also said he wants to do a branch of his tutorial on inner roots. Given that inner roots is probably the single most powerful feature of the XDI graph model, I personally don't think we can have enough documentation or examples of it.

But above all, we need them for THIS SPEC, since the very concept of link contracts depends on using inner roots to describe the AA/RA relationship that the LC governs.

6)    Have we ever discussed policy inheritance with link contracts or does each link contract context override all contexts higher in the graph?

OMG my head just exploded ;-)

Seriously, yes, that has been discussed, but more in the sense that link contracts could reference other link contracts. 

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.

Great topic to discuss tomorrow (if there is time after the higher topics). 

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

It's a very good question which spec is going to define how to extend $do. Let's add that to the list for tomorrow. 

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

You are good ;-)

To be discussed.

 

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

$newer and $older ;-)

Seriously, let's discuss.

 

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

Yes, that's a known question for link contracts, and another one for tomorrow (that we'll almost certainly not get too).

I suggest that there are enough issues here that we should maintain a list of open LC questions on the wiki even before we start turning them into specific Jira issues—but that's up to you.

Looking forward to the call tomorrow,

=Drummond