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

[Dan Blum <dan@respectnetwork.net>]

Thanks so much for the help in answering these questions. Most of it we can talk about on the call. 

Note that I'm trying to get some kind of working draft done in two weeks so that when evaluators go to look at XDI this will be there. Note that it will need to have more XDI statements and examples from you and Markus because I cannot write most of these.

Assuming under these circumstances you think its worth my continuing to try to have a working draft, we need to answer as many questions as possible, especially about link contract establishment.

 comments on your answers:

 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).

yes, I'm only looking at the XDI flows, don't care how we got to them for this spec 

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.

that is not what it said in Markus' walkthrough document, but I agree that would make more sense and can document it that way   

1. 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. 
   

there was no such statement in the LC patterns in the wiki

would it make sense by default to return both and leave the possibility of a dataless option for a future spec enhancement?

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. 

that is not what it said in Markus' walkthrough document,  but I agree that would make more sense and can document it that way

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."

 

good, I like that

 

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.)

I can document it in english bullet points as a start

 

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. 

agreed 

 

1)    Should the RA just store the address of t

 

he 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. 

the spec could say that the RA has the option to do this 

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. 

maybe not worth the complexity 

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. 

agreed 

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. 

this could be recommended as the default approach 

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.

$copy would be a simple usage policy that we can use - but it is only going to make sense in the context of a trust framework

once the copy is made, consistency will be problem and we have no notification mechanism in this spec or implemented in working code

our only simple spec option is to recommend that the RA should poll periodically

 

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. 

I'll put them in 

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.

That's was I asking - please provide an actual example XDI statement or syntactic definition that makes the AA check to see if the requester is authenticated 

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".

agreed about the acronyms, consider it done

what does the unsuccessful link contract establishment message look like? 

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. 

maybe by default all the requested attributes are mandatory but you can add a $optional context or something like that to the optional ones; if the AA doesn't want to provide all the mandatory ones it must fail the request 

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. 

how does an LC reference another LC, why would it do that, and what is an example XDI statement? 

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). 

I'm happy to put inheritance into the issues list for now 

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. 

what does an XDI statement for "extension" look like? 

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.

 

That could work, but what a generic model for data typing and matching? I'm happy to add that to the issues list 

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.

I want to get a spec done with as many answered as possible and the two week time frame is to short for issues list to be helpful. However, we could use an issues list to document what we don't get done.

 

Looking forward to the call tomorrow,

=Drummond