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 Thursday 2011-12-01


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

Date:  Thursday, 01 December 2011 USA
Time:  1:00PM - 2:00PM Pacific Time (20:00-21:30 UTC)

ATTENDING

Giovanni Bartolomeo
Mike Schwartz
Joseph Boyle 
Markus Sabadello
Drummond Reed 


THE IDEARPAD LINK FOR TODAY IS:
     http://xdi.idearpad.org/46


1) IDTRUST BUDGET

Mike Schwartz and Markus Sabadello reported that the info at the following has been submitted, no word back yet.

  http://ox.gluu.org/doku.php?id=idtrust:proposal

# MIKE will check with Dee Schur about feedback/suggestions/timing.

2) OPENXDI UPDATE

Mike made a quick demo of the updated OXServer and OXGraph utility.

He started by showing OXAuth which uses OpenID Connect 1.0, JWT (JSON Web Tokens), JWK (JSON Web Key), and soon will add SWD (Simple Web Discovery). OpenID Connect 1.0 adds additional semantics on top of OAuth 2.0 that are necessary for authentication and authorization. OpenID Connect 1.0 specifies the token formats and semantics that are necessary for this - a subset of the semantics that are in SAML.

All of this has nothing to do with XDI directly - it simply provides an OAuth service for issuing and validating tokens for accessing the XDI server.

Once authenticated, the XDI server now has a service for requesting a graph, either by entering the bound XRI of the target graph and the link contract, or by explicitly typing out the request message.

http://seed.gluu.org/oxServer/

mike / secret is a test account

Mike said that as soon as it goes live, any TC member will be able to get an account and starting testing it and managing their own personal graph.


3) XDI GET PARAMETERS FOR LIMITING GRAPH SCOPE

As graphs get very large, it would be useful to specify how many levels  relational arcs should be resolved (i.e. how many referrals are  appropriate). A proposal from Mike and Drummond:

=abc/+xyz($n) Where n would specify the number of levels to retrieve. If  the ($n) portion is ommitted, the relational arc is assumed to retrieve  the subtree. 0 = node only. -1 can be used to explicty set subtree  search.

Mike further explained the problem, which is that relational links could be to other servers. Each server could request on level less of the initial total from the next server in the chain.

Drummond mentioned that this pattern has come up a number of other times in the history of the TC, and pointed out that that there are two close analogies: the way DNS resolution works and the way HTML pages containing links to graphics work. 

In the DNS resolution case, a resolver client can hand off to a nameserver the job of resolving a multi-segment name. In the HTML case, a browser client simply asks a server for an HTML page, then asks it (or other servers) for links to any graphics or other embedded objects on that page.

After a short discussion there was consensus that we should start out very closely to the HTML model, i.e., with the following rule: an XDI server should return all relational arcs within the graph that has been requested from it. It is the responsibility of the XDI client to resolve any relational arcs that point outside that graph.


4) $ALL

Mike is suggesting that we define a  $word that covers all XDI graph operations (e.g., $get, $add, $mod,  $del). His suggestion was $all.

The primary use case is administrators of XDI graphs and servers.

There was general consensus that having a $word representing a collection of the four atomic graph operations ($get, $add, $mod, $del) is a good idea.

We then discussed a second question: should that $word include $copy and $move? The general consensus was yes.

We then considered the best human language semantics for the $word? Candidates discussed include:

The consensus was to go with $all.

A final issue was pointed out by Drummond: XDI operations are extensible by extending $do, e.g., $do@foo+operation. Should $all cover these extended operations?

Drummond suggests the answer to that should be no, that should be a separate permission, however that permission should be $do$all.

There was consensus to take that approach.


5) RULES FOR WHEN TO USE I-NAMES AND WHEN TO USE I-NUMBERS

Mike is asking whether the TC should specify guidelines or best practices for this. We took the time to revisit the first pattern in the XDI Graph Patterns document, showing the use of $is arcs to express canonical relationships between i-names and i-numbers, and Mike agreed that pattern answered his question. He still wants to further explore best practices for when to use +words vs *names.


6) OBJECT GRAPH MAPPING

Mike said that the OpenXDI Project team plans to have its object graph mapping process implemented by next week, and then that will lead to an independent implementation, so now is a good time for other TC members to look over it. It's like "Hibernate for XDI". It needs more testing, so any TC members who are interested can try it out.

# MIKE wil send a link to the documentation and code to the list.


6) 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]