OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Minutes: XDI TC Telecon Friday 2014-05-16


XDI TC Minutes


Following are the minutes of the unofficial telecon of the XDI TC at:


Date:  Friday, 16 May 2014 USA
Time:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)

ATTENDING

Animesh Chowdhury
Dan Blum
Peter Davis
Markus Sabadello
Hubert Le Van Gong
Will Martin
Les Chasen
Joseph Boyle

GUESTS

REGRETS

Drummond Reed
Phil Windley

NEWS & UPDATES

None scheduled.

PRESENTATIONS/DISCUSSIONS

Broken links in spec draft

Lionel of Emmett Global has raised concerns that broken links in the following document will cause confusion:

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

Can we fix them?

XDI Policies

We reviewed Dan’s document about XDI policies:

https://www.oasis-open.org/committees/download.php/52892/XDIPolicyDraft.docx


Dan explained that this document incorporates materials from various XDI TC wiki pages and other sources, e.g. policy expressions, and link contract patterns.


We re-confirmed our impression that we now have three different types of policies (link contract policies, message policies, data usage policies) which all share some fundamental constructs such as $and, $or, $true, $false, etc.


We came up with the following example, which illustrates a data usage policy 1. directly attached to data, and 2. attached to a link contract:



=markus<#email>&/&/"...."


=markus$to=hubert$from$do/$get/=markus<#email>

=markus$to=hubert$from$do$if$and... { you have to be hubert }                   <-- link contract policy

=markus$to=hubert$from$do$if$and... { you have to send a valid password ...}    <-- link contract policy


$use$if$and...     { you have to encrypt the data }      <-- data usage policy

$use$if$and$not... { you may not cache the data }        <-- data usage policy


1. Data usage policy part of the data:


=markus<#email>&/&/"...."

=markus<#email>$use$if$and...     { you have to encrypt the data }      <-- data usage policy

=markus<#email>$use$if$and$not... { you may not cache the data }        <-- data usage policy


2. Data usage policy part of the link contract:


=markus$to=hubert$from$do/$get/=markus<#email>

=markus$to=hubert$from$do$use$if$and...     { you have to encrypt the data }      <-- data usage policy

=markus$to=hubert$from$do$use$if$and$not... { you may not cache the data }        <-- data usage policy

=markus$to=hubert$from$do$if$and... { you have to be hubert }                     <-- link contract policy

=markus$to=hubert$from$do$if$and... { you have to send a valid password ...}      <-- link contract policy


Example message sent by Hubert:


=hubert[$msg]!:uuid:1234$do/$get/=markus<#email>

=hubert[$msg]!:uuid:1234/$do/=markus$to=hubert$from$do


One question that was raised: In the second case (data usage policy is part of the link contract), would the data usage policy actually be returned in the message response? Note that =hubert is only requesting =markus<#email>, not the link contract.


Dan mentioned that in Respect Connect, both parties of a connection are supposed to have a copy of the same link contract instance and therefore also hold the data usage policy. Markus replied that this is specific to Respect Connect. In the general case, an XDI client does not necessarily have a copy of the link contract it is operating under.


XDI Signatures

Animesh, Peter and others have continued work on XDI signatures:

https://lists.oasis-open.org/archives/xdi/201405/msg00020.html


In this thread, Peter has formulated a number of requirements, such as the ability to sign entire subgraph, or individual statements.


Joseph asked if there was a way to reify XDI statements. Markus said that in his perception, there is no statement reification in XDI as there is in RDF, but Markus also noted that Drummond might have a different idea about this :)


Another topic we discussed was whether an XDI server would automatically generate and/or validate signatures in a graph. Markus explained that in the XDI2 implementation, servers validate signatures on incoming XDI messages, but servers take no part in generating and/or validating signatures stored in a graph the server has persisted. This led to a longer discussion about “persistent” vs. “non persistent” graphs.


We agreed this was a second step and not immediately relevant to the main topic, which is how signatures are expressed in XDI, and what part(s) of a graph they cover.


Peter concluded that he thinks he knows enough to proceed with his spec draft and will give an update next week.

XDI Core spec feedback

Joseph removed broken links in his XDI Core v1.0 Working Draft, after a request by Lionel Wolberger:

http://xdi.org/xdi-spec-docbook/xdi/xdi-core-1.0/xdi-core-1.0-wd02.xml#idm25095520

Joseph explained that the reason for the broken links is that we were using a temporary location for the draft (under XDI.org), while the spec template assumes proper publication of the draft within the OASIS system. Once we public a spec in OASIS, the links will work. Peter and Markus agreed that we should probably only point people to spec drafts at the “official” OASIS repository, rather than temporary locations. Especially now as we expect growing interest in the XDI spec by a wider community.

Joseph then requested feedback on the contents of his draft.

Markus made a comment that inner roots probably need some more explanation.

If you have an inner root, e.g.

//(=example.1/#nominated)

then you also always have this:

=example.1/#nominated/(=example.1/#nominated)

The serialization parameters (e.g. inner, implied) are not covered at all yet by the XDI Core spec. There probably needs to be a separate section that explains how (de-) serialization works, in addition to the raw grammar that’s currently in the draft.

We discussed which aspects of (de-)serialization should be covered by the Messaging and Binding specs. Markus’ sense is that the only thing the Binding spec should cover is the way how certain serialization formats and their parameters are being requested. The entire mechanics of (de-)serialization itself should be in the Core spec.

We considered whether Core should have an introductory part that talks about XDI in general and also provides an overview of all the other XDI specs. Dan mentioned he had worked on XDI-related materials at http://info.respectnetwork.com/, maybe some of this could be re-used for the XDI specs.

Report from XDI editors subcommittee

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

https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook


We did not have time for the weekly scrum report. The XDI editors subcommittee is holding its own weekly calls now.

NEXT CALL

The next call is next week at the regular time.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]