Re: [xdi] XDI TC Notes Unofficial Telecon Friday 2015-10-05

["=Drummond Reed" <drummond@respect.network>]

Markus, great notes, thanks.

I just want to second one conclusion we came to on the call: 

"Therefore, there may be a need for more expressive XDI policy features with different branches producing more diverse results than just true and false."

I think this is very important. An XDI message processor should be able to evaluate explicit policy branching logic to arrive at a decision about what happens to an XDI message. A simple solution would be:

1. The policy branching logic describes the order in which different policy branches are evaluated.
   
2. The first policy to result to evaluate to true wins.
3. If all policies evaluate to false, the message is rejected.

Thoughts?

=Drummond 

On Tue, Oct 6, 2015 at 2:11 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

XDI TC Notes

Following are the notes of the unofficial telecon of the XDI TC held on:

Date: Monday, 5 October 2015 USA
Time: 10:00AM - 11:30AM Pacific Time (17:00-18:30 UTC)

The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken.

ATTENDING

Lionel Wolberger
Markus Sabadello
Drummond Reed
Les Chasen
Christopher Allen

REGRETS

Phil Windley

AGENDA

XDI Core: Spec Drafting Update

Joseph has been working on converting Drummond’s finished sections into DocBook XML. Although Joseph was not able to attend the meeting, he has posted the first cut on Working Draft 05 at:

http://xdi.org/xdi-spec-docbook/xdi/xdi-core-1.0/xdi-core-1.0-wd05.xml

Note that he is still working on adjusting the level of headings and that some WD04 text (such as section 5) still needs updating with Drummond’s new text.

XDI Core ABNF

Drummond completed a revision of the ABNF to incorporate all revisions and simplifications coming out of completing all sections of XDI Core 1.0 for Working Draft 05.

https://wiki.oasis-open.org/xdi/XdiAbnf

The previous ABNF from Working Draft 04 is still on the wiki page so you can compare the two. We reviewed all the key changes:

Substantive Changes

1. Peer root / inner root sequence order enforced (it had not been earlier)

2. Root collections and root definitions removed (complexity not needed)

3. Class & instance entities revised/simplified (to match the spec)

4. Immutability and relativity symbol patterns enforced (simpler and more regular)

5. XDI Identifiers section simplified & revised for final XDI schemes

6. IRI character rules (vs previous URI character rules)

7. Lowercase alpha characters in XDI names enforced (vs. previous ALPHA rule)

Cosmetic Changes

1. REAL sequences introduced (to simplify ABNF in the XDI Statements section)

2. Used character rules from IRI

Markus wondered if these these rules needed to include the literal character option (i.e., the terminal & character):

direct-relational       = root-ent-attr-lit-seq "/" 1*entity "/" root-ent-attr-lit-seq
inverse-relational      = root-ent-attr-lit-seq "/$is" 1*entity "/" root-ent-attr-lit-seq

Drummond said yes, in order to enable statements like:

.../$get/=drummond<#email>&

That statement will retrieve only the value of =drummond<#email> if present (and nothing if not).

It will also enable statements like:

=drummond<#email>&/$is/$true

This statement can be used in a policy to confirm that an attribute has a value.

Markus also asked about the literal statements:

literal-statement       = root-ent-attr-seq attr-terminal "/&/" value
literal-var-statement   = root-ent-attr-seq attr-terminal "/{&}/" value-variable
value-variable          = "{" attr-class "}"

He wondered if the literal-var-statement statement needed to conclude with an attr-terminal.

attr-terminal           = attr-class / ( attr-collection attr-instance )

Drummond said yes, because an instantiation of a literal-var-statement statement must then be a valid literal-statement, and the subject of a literal-statement must end is an attr-terminal.

We discussed a bit the relevance of the ABNF for XDI implementations. Markus recalled that there are several tools for generating parsers from an ABNF (e.g. aParse2 and APG), but that in using them there is a trade-off between performance and correctness. Markus also recalled that Joseph had been arguing in favor of lightweight and efficient “hand-coded” parsing code as opposed to auto-generated parsers.

The next step is for all TC members, and especially Joseph, to review the ABNF in detail, including testing via a parser generator, to see if they can find any other bugs.

XDI Core Remaining Steps

We reviewed the remaining steps necessary to hold the Committee Specification Draft vote beginning on October 19.

• Complete DocBook conversion

• ABNF and Serialization section reviews

• Introduction section

• Introduction

• Example XDI Graph

• XDI Specifications Table

• Appendices

Drummond suggests drafting the Introduction as a Google doc so that everyone can edit and comment on it online in real time.

Messaging Walkthrough and XDI Channels

In addition to his previous “messaging walkthrough” wiki pages:

https://wiki.oasis-open.org/xdi/MessagingWalkthrough

https://wiki.oasis-open.org/xdi/ChangeOfAddressWalkthrough

Markus posted two new documents:

https://www.oasis-open.org/committees/download.php/56631/SecureMessaging-text.pdf

https://www.oasis-open.org/committees/download.php/56632/SecureMessaging-diagram.pdf

These are first versions of a complete working flow between two XDI actors involving a bi-directional connection that enables the exchange of simple chat messages.

We discussed that the purpose of link contracts is not only to authorize messages at a recipient’s XDI endpoint, but also to indicate requirements for the message at the sender’s XDI endpoint, e.g.:

• Authentication

• Signature

• Valid Hash

• Encryption

• Return Receipt requested/required

• Permitted bindings

• Binding-specific information, e.g. allowed latency, IP address

The challenge here is that link contract policies are represented as a logic tree with a set of conditions that can be easily evaluated against a given message, but it may be difficult to “reverse-engineer” the requirements when constructing a new message.

Related to the topic of policies and the “messaging walkthrough”, Markus also brought up a use case where link contract evaluation needs to have more diverse outcomes. E.g. instead of a boolean result “not authorized” / “authorized”, there may be a need for distinguishing between

:

1. Authorized immediately

2. Not authorized and rejected

3. Not authorized and deferred with push link contract for the result

4. Not authorized and deferred without push link contract for the result

This distinction is important for advanced operations such as connection requests and invitations. One approach Markus has been experimenting with is the use of multiple policies, all of which have a boolean true/false outcome, e.g.:

(=drummond/$public)$do/$get/=drummond<$public><$key>

(=drummond/$public)($do$if$and/$true){$msg}<$sig><$valid>/&/$true

(=drummond/$public)($do$if$and/$true){$msg}<$sig>/$is#/$rsa$2048

(=drummond/$public)$do$hold$if/$true/$true

(=drummond/$public)$do$hold$push$if/$true/$true

Note that there are three policies, under the $do$if branch, the $do$hold$if branch, and the $do$hold$push$if branch. With this approach however, the exact processing logic is not actually expressed in XDI itself. Therefore, there may be a need for more expressive XDI policy features with different branches producing more diverse results than just true and false.

We also talked a bit about encrypted messages. Markus mentioned that he had experimented with XDI encryption:

https://server.xdi2.org/XDIEncrypter

There are both parallels and differences between signing and encryption. We noted that when decrypting an incoming XDI message, there may be different ways of doing that, e.g. with a private key stored in the graph, or an HSM, or remote decryption services, etc. This should be an abstract mechanism and invisible on the XDI messaging level.

NEXT REGULAR CALL

The next call is next week at the usual time (Monday 10AM PT). The link to where agenda items can be posted for the next meeting is: https://docs.google.com/document/d/19oDl0lbb56Grehx2a5flZnhrgnua5l8cVvC_dJ8fTXk/edit?usp=sharing