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
- From: Drummond Reed <drummond.reed@xdi.org>
- To: OASIS - XDI TC <xdi@lists.oasis-open.org>
- Date: Sat, 3 Dec 2011 10:30:44 -0800
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:
1) IDTRUST BUDGET
Mike Schwartz and Markus Sabadello reported that the info at the following has been submitted, no word back yet.
# 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.
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]