Minutes: XDI TC Telecon Thursday 2011-10-13

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

Date:  Thursday, 06 October 2011 USA

Time:  1:00PM - 2:00PM Pacific Time (20:00-21:30 UTC)

ATTENDING

Mike Schwartz

Markus Sabadello

Joseph Boyle 

Drummond Reed 

THE ETHERPAD LINK FOR TODAY IS:

     http://piratepad.net/SUlNdTZ26A

1) RELATIVE VS ABSOLUTE ORDERING

From a message Mike Schwartz sent to the TC list:

There has been some discussion at Gluu about the sample XDI Drummond published on : http://wiki.oasis-open.org/xdi/XdiDiscovery

Drummond
 has expressed an idea that relative ordering should be supported. For 
example  the following could all specify different  orders:

 [*1, *2, *3] [a*1, a*2, a*3] [b*1, b*2, b*3]

This feature is not currently supported in oxGraph--only the first ordering is supported [*1, *2, *3...].

I
 think it would be equally clear to use a subcontext to acheive this  
result. Does the standard really need relative ordering if it can be  
achieved with a subcontext? See attached sample graph:

   http://lists.oasis-open.org/archives/xdi/201110/pngX1hPUN0FOf.png

We discussed the difference between the approaches, and compared it to the patterns in agenda item #2 below.

After
 a long discussion we did not arrive at a clear conclusion yet. What is 
clear is that ordering within subtypes is just another example of 
subtypes, and that there are several clear patterns for how subtyping 
can be applied. We need to cook on which of these patterns will be 
optimal and thus should be recommended (or required by certains specs, 
such as XDI Discovery).

One
 other key insight was that Mike & the OpenXDI team is planning for 
an XDI server to be able to control the output of an XDI request, for 
example, ordering of the XDI graph statements. This requires both 
uniform semantics of ordering within the graph AND a standard semantic 
for requesting the server to do the ordering. This is another action 
item for the TC.

Mike
 pointed out that this pattern also extends to other forms of search 
controls searchs that an endpoint might want to subscribe to. He said it could also be thought of as a trigger or persistent search.  He originally thought of proposing $modify for this; Drummond suggested that $copy could be used, as this has been the proposed XDI operation for synchronization.

In
 the LDAP standard, "search controls" are defined and then servers 
advertise that these search controls are supported.Persistent Search, 
and Server Side Sorting are two examples. But timeouts and max nodes returned could also be specified in the search controls.

2) SUBTYPING OF DISCOVERY ENDPOINTS

On
 a related note to the discussion above, Drummond replied to Mike's 
email on the list saying that another issue that needs to be addressed 
for XDI discovery is subtyping of endpoint types. For example, what if 
a  client wants to make a discovery query for only the https XDI 1.0  
endpoint, i.e., the client knows it only want to use https and don't 
even want to  see any other XDI endpoint types.

Just
 as with the ordering problem, it can be done EITHER with a  subcontext 
(or supercontext) of $uri, or it can be done with a  subcontext (or 
supercontext) of the $xdi$v!1 relational arc inside the  $uri context. 
Examples of all four options:

a) SUBCONTEXT OF $URI

=!1111$uri$https/!1!/(data:,https:%2F%2Fxdi.example.com%2F)

=!1111$uri$https/$xdi$v$1/!1!

b) SUPERCONTEXT OF $URI

=!1111$https$uri/!1!/(data:,https:%2F%2Fxdi.example.com%2F)

=!1111$https$uri/$xdi$v$1/!1!

c) SUBCONTEXT OF $XDI$V!1

=!1111$uri/!1!/(data:,https:%2F%2Fxdi.example.com%2F)

=!1111$uri/$xdi$v$1$https/!1!

d) SUPERCONTEXT OF $XDI$V!1

=!1111$uri/!1!/(data:,https:%2F%2Fxdi.example.com%2F)

=!1111$uri/$https$xdi$v$1/!1!

At first blush, Mike and Drummond both preferred (c) for two reasons:

 
 1) It keeps the graph flatter by just using the $uri context, reflect 
the "context data typing rule", i.e., all data of the same data type can
 go in the same context, and then by subtyped within that context.

 
 2) Within the relational arcs, subtyping is done from most 
important/broadest-grained attribute to least important/finest-grained. 
In this case, most important is that it is an XDI endpoint.

However after further discussion and review of Mike's visual XDI graph example, another variant became clear:

e) SUBCONTEXT OF $URI USED ONLY FOR REFERENCES

=!1111$uri/!1!/(data:,https:%2F%2Fxdi.example.com%2F)

=!1111$uri$xdi$v$1$https/*1/(=!1111$uri/!1!)

We
 agreed we need to cook on this further to see which of these patterns 
should be recommended (or, in the case of certain specs, required).

3) LINK CONTRACT REFERENCE IN XDI MESSAGES AND PUBLIC LINK CONTRACT REFERENCES

These two related issues, while minor, have been pending for some time. See:

  http://lists.oasis-open.org/archives/xdi/201106/msg00041.html

  http://wiki.oasis-open.org/xdi/XdiMessagePatterns

Currently our message template from http://wiki.oasis-open.org/xdi/XdiMessagePatterns iis:

()/$/{from-endpoint}

{from}$msg{id}/$()/{to-endpoint}

{from}$msg{id}/$d!/(data:,{datestamp})

{from}$msg{id}$do/{operation}/{target}

The proposal to add link contract references is:

()/$/{from-endpoint}

{from}$msg{id}/$()/{to-endpoint}

{from}$msg{id}/$d!/(data:,{datestamp})

{from}$msg{id}/$do/({link-contract})  <== LINK CONTRACT REFERENCE

{from}$msg{id}$do/{operation}/{target}

Where
 {link-contract} is the XRI of the root node of the applicable link 
contract. For public link contracts (i.e., link contracts where rights 
are unrestricted), this XRI is $public.

Mike noted that this needs to be checked in the OpenXDI server, which implements a previous version: 

{from}$msg{id}$do/$do/({link-contract}) 

Drummond explained that after more consideration, the extra $do is extraneous, since
 the link contract reference appears only in a message and not in the 
link contract itself, which the previous proposal would suggest. For 
this reason we should remove it for clarity.

4) STORING AUTHENTICATION INFORMATION IN THE GRAPH

Mike
 explained that OpenXDI needs to be able to support authentication about
 how a client should authenticate to the server, particularly if it is 
not using "native" XDI authentication via signed a signed XDI request 
message. In this case we need to push the necessary metadata for other 
forms of authentication, such as OAuth, into the graph.

Mike
 asked what spec this would be part of. Drummond suggested that it could
 fit with either XDI Discovery or XDI Signatures, or it could be a 
separate spec, XDI Authentication. He explained that as long as 
authentication was assumed to use XDI Signatures, it could just be 
specified there. But if we believe XDI servers should support other 
authentication models, such as SAML, OpenID, or OAuth, then we will need
 a separate spec that defines:

The dictionary, i.e., how the necessary metadata is pushed into the XDI graph.

The profiles for using other authentication protocols such as SAML, OpenID, or OAuth.

5) OXPLUS, OXMODEL, AND OXWALL

Mike
 showed OxPlus, an interface prototype and a working model of an XDI 
graph for a social wall. OxPlus is written to use the OxModel module of 
the OpenXDI Project. OxModel is publishing all the REST interfaces will 
allow developers to write apps for an OpenXDI server using REST, and the
 server will handle the XDI transparently on the back end, i.e., REST in
 and XDI out. OxWall is one of those interfaces designed to implement a 
social wall similar to an aspect in Diaspora.

6) INTERNET IDENTITY WORKSHOP PREP

Drummond,
 Markus, Mike, and Joseph will all be at IIW next week and are planning 
multiiple sessions on XDI and OpenXDI related topics.

7) NEXT CALL

There will be no call next week due to Internet Identity Workshop. The next call will be the following week at the regular time.