xdi message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Minutes: XDI TC Telecon Thursday 2011-10-13
- From: Drummond Reed <drummond.reed@xdi.org>
- To: OASIS - XDI TC <xdi@lists.oasis-open.org>
- Date: Thu, 13 Oct 2011 18:25:42 -0700
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:
1) RELATIVE VS ABSOLUTE ORDERING
From a message Mike Schwartz sent to the TC list:
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:
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
b) SUPERCONTEXT OF $URI
c) SUBCONTEXT OF $XDI$V!1
d) SUPERCONTEXT OF $XDI$V!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
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:
()/$/{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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
