[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2015-04-17
Following are the minutes of the unofficial telecon of the XDI TC held on:
Date: Friday, 17 April 2015 USA
Time: 09:00AM - 10:30AM Pacific Time
Drummond Reed
Peter Davis
Joseph Boyle
Markus Sabadello
Phil Windley
William Dyson
Les Chasen
Drummond uploaded another draft section of XDI Core 1.0—the Collections section (which is NOT marked with Track Changes because it’s all new). There are also a few text revisions to earlier sections marked with Track Changes.
https://www.oasis-open.org/committees/document.php?document_id=55472&wg_abbrev=xdi
You can see where this fits in the full outline of XDI Core 1.0:
https://wiki.oasis-open.org/xdi/CoreSpecOutline
Joseph has all existing content except the section above in DocBook at:
http://xdi.org/xdi-spec-docbook/xdi/xdi-core-1.0/xdi-core-1.0-wd04.xml
Drummond suggested the terms “subcontext” and “supercontext” as alternatives for “child context” and “parent context”. Joseph and Markus said they liked the terms.
We briefly discussed the namespace concept of Onename, which uses the + symbol. Drummond explained that in XDI, having two namespaces for ="" and +legal authorities is important for several reasons: 1. It makes it possible to clearly identify personal data vs. non-personal data, and 2. this in turn makes it easier to apply security and privacy policies to different XDI subgraphs depending on the authority and the context.
Peter advised that when it comes to data ownerships and policies, language should be kept as generic as possible to avoid ambiguous viewpoints.
Drummond then explained the new content in the Collections section. Two key points in this section:
The definition of collections vs. singletons.
Collections can themselves be described, i.e. have attributes.
Markus feedback was that the section feel well-written and complements some concepts introduced in the “Classes” section.
Markus asked about the need for “root collections”, which are allowed in the ABNF. Drummond gave the following example for modeling roots based on an entity collection and its members. He began with a set of example addresses is for the entities, such as a collection of devices:
[#gadget]*!:uuid:ex.01
[#gadget]*!:uuid:ex.02
[#gadget]*!:uuid:ex.03
The use case is that the XDI authority wants to maintain separate graphs for each member of the collection, for example when each member of the collection is a separate device, with its own network address. While all the devices logically belong to a single collection, each device has its own XDI graph at its own XDI endpoint. This is a case where the collection itself would be a peer root, and each member could be its own subroot.
([#gadget])(*!:uuid:ex.01)
([#gadget])(*!:uuid:ex.02)
([#gadget])(*!:uuid:ex.03)
Joseph noted that our syntax for collections does not indicate at the level of the collection whether member instances are ordered or unordered. In fact, it allows for both. However, this does parallel the distinction between integer-indexed arrays (usually called just “arrays”) in JSON and in most programming languages, and associative arrays such as JSON/_javascript_ “objects” = Perl “hashes” = C++ and Java “maps” = key/value database tables. Joseph suggested that perhaps we should make these parallels explicit in the spec.
http://en.wikipedia.org/wiki/Associative_array
http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(mapping)
Markus suggested that we need both an example of ordered members and an example showing the ordered/unordered pattern. This could be called the “ordered/unordered reference pattern”, analogous to the “singleton/collection reference pattern”.
#ACTION ITEM: Drummond to add the text Joseph suggested and examples Markus suggested to the next draft.
Joseph still feels that marking collection vs. singleton value with brackets on the collection name itself is odd compared to most languages and compared to XDI’s marking ordered collection vs. unordered collection on the index instead of on the collection name. Drummond noted we have discussed this before and asked what the alternative would be. Joseph can make a written proposal.
We also discussed a convention for example UUIDs in TC documents. Drummond is currently using *!:uuid:ex.01, *!:uuid:ex.02, etc. Markus has been using *!:uuid:1111, *!:uuid:2222, etc.
http://xdi.org/xdi-spec-docbook/xdi/xdi-messaging-1.0/xdi-messaging-1.0-wd03.xml
http://xdi.org/xdi-spec-docbook/xdi/xdi-bindings-1.0/xdi-bindings-1.0-wd03.xml
Markus also uploaded this set of slides describing the Messaging and Bindings specs and highlighting several open issues:
https://www.oasis-open.org/committees/document.php?document_id=55478&wg_abbrev=xdi
Markus explained his current thinking about concepts, syntax, and functionality that is “generic” to XDI Messaging, such as request messages, response messages, etc., and about the “specifics” of the individual bindings.
Markus ave an overview of the 3 bindings that are currently defined:
XDI Direct Binding
XDI Browser Binding
XDI WebSocket Binding
One question was whether a WebSocket endpoint (e.g. wss://my.xdi.com/=markus) should be assumed to use the same host and port as the “direct” XDI endpoint (e.g. https://my.xdi.com/=markus), or whether it should be separately discoverable. Peter argued that it should not be assumed to be the same, since the endpoint URIs are actually different. Markus agreed.
We discussed the terms “plain response message”, “deferred response message”, “full response message”. Please suggest better terms if you have ideas.
Drummond asked whether a requester can “force” a full response message instead of a plain response message. Markus replied that this is possible with the <$full> message parameter. Drummond suggested that the spec should provide some guidance when this should be used (e.g. for security reasons).
We discussed whether XDI agents need their own XDI addresses for messaging (e.g. *!:uuid:ex.01), or whether they should just act “on behalf” an authority (e.g. =markus). Drummond mentioned the OAuth 2.0 spec, which has a special “resource owner” flow for the latter use case.
We reaffirmed that all topics related to key managements, encryption, signatures, etc. should be covered by separate documents (XDI Cryptographic Profiles, XDI Security Mechanisms, XDI Privacy Mechanisms).
Markus posted an updated document after the call, with some bugs fixed:
https://www.oasis-open.org/committees/document.php?document_id=55485&wg_abbrev=xdi
At last week’s F2F meeting at Internet Identity Workshop in Mountain View, CA, the TC members present discussed but did not reach consensus on the local name syntax issue. Drummond has done a writeup on this issue to help us move to closure:
https://wiki.oasis-open.org/xdi/LocalNameSyntax
#ACTION ITEM: We did not discuss this topic, but agreed that everyone should review it before the next call.
We did not discuss this topic, but we did discuss the use of $push during the “XDI Messaging and Bindings” discussion. We will discuss this further on the 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]