XDI TC Notes Unofficial Telecon Friday 2015-06-29

[Markus Sabadello <markus.sabadello@xdi.org>]

XDI TC Notes

Following are the notes of the unofficial telecon of the XDI TC held on:

Date:  Monday, 29 June 2015 USA
Time:  10:00AM - 11:30AM Pacific Time

The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken.

ATTENDING

Peter Davis
Markus Sabadello
Drummond Reed

REGRETS

AGENDA

The Taxonomy of Instances

While working on XDI Core, Drummond noted an inconsistency in our treatment of instances. In Working Draft 04, we say:

• $ and # are the context symbols for classes (reserved and unreserved)

• @ and * are the context symbols for instances (ordered and unordered)

• = and + are the context symbols for authorities (personal and legal)

In each case, the context symbols by themselves represent classes. What’s special about $ and # is that they represent abstract classes:

• $ represents the abstract class of all reserved classes

• # represents the abstract class of all unreserved classes

This means all $ and # identifiers represent classes, which of of course can be derived from other classes using a type statement. Example:

#cat/$is#/#animal

The other four context symbols—@, *, =, and +—when used by themselves do not represent abstract classes. Rather they represent concrete classes, which means that every instance of an identifier in these four spaces represents an instance of that class. For example:

• @3 represents the third instance in a collection

• *foo represents the thing “foo”

• =foo represents the person “foo”

• +foo represents the legal entity “foo”

So the inconsistency is that in Working Draft 04, we define only identifiers that begin with @ and * as “instances”. We don’t define identifiers that begin with = and + as “instances”.

The practical effect of this is that in a collection, only the @ and * child nodes of the collection are considered members of the collection. To quote from the Collection section:

The set of context nodes that belong to the collection are called its members. To be a member of a collection, a context node MUST be: a) a child subcontext of the collection node, and b) either an ordered instance or an unordered instance.

However we do specifically say that a collection can contain both @ and * members, and cite the example of the ordered/unordered reference pattern:

{

    "=example": {

      "[<#email>]<@0>": {

          "/$ref": [

             "=example[<#email>]<*!:uuid:x-1>"

          ]

      },

      "[<#email>]<@1>": {

          "/$ref": [

             "=example[<#email>]<*!:uuid:x-2>"

          ]

      },

      "[<#email>]<@2>": {

          "/$ref": [

             "=example[<#email>]<*!:uuid:x-3>"

          ]

      },

      "[<#email>]<*!:uuid:x-1>": {

          "&": "alice@example.com"

      },

      "[<#email>]<*!:uuid:x-2>": {

          "&": "alice.roth@example.net"

      },

      "[<#email>]<*!:uuid:x-3>": {

          "&": "stillalice@example.org"

      },

      "[<#email>]<$t>": {

          "&": "2010-09-20T10:11:12Z"

      }

    }

}

So the inconsistency is that = and + identifiers are also unordered instances that behave in every other way like * identifiers, yet we do not define them as “instances” in the same way.

The fix is simple: just define that all instances of @, *, =, + identifiers represent members of a collection when they appear as child nodes of the collection. This also makes collections more intuitive and useful. For example, a [#friend]collection could now explicitly include people:

=drummond[#friend]=markus

=drummond[#friend]=les.chasen

=drummond[#friend]=windley

And on the business side, a [#partner]collection could now explicitly include organizations:

+example-company[#partner]+example-company-2

+example-company[#partner]+example-company-3

+example-company[#partner]+example-company-4

In short, a collection can contain any set of instances of @, *, =, or + identifiers.

We discussed the pattern that you can always make a member instance of a collection a $ref to another node in the graph. However Drummond noted that when this is done, it would be semantically consistent for a ref to an = node to itself be an =node. Example:

=drummond[#friend]=!:uuid:x-1/$ref/=markus

Peter asked if there was an effect on the ABNF. Drummond said he believed not; the change will just be an update to the spec text specifying what constitutes the members of a collection.

Apps as Legal Agents

In the work on secure messaging, the need has arisen to be able to identify:

1. The legal authority for an app responsible for sending/receiving XDI messages

2. The specific identity of an instance of that app being run on a specific device.

For example, if the owner of a personal cloud wants to authorize an XDI messaging app on a mobile device to send/receive messages from her personal cloud. This requires a link contract between the instance of the app and the personal cloud.

In order to fully identify the app instance as a legal agent, i.e., as a piece of code from a publisher who bears some legal responsibility for the operation of that code, following is the initial proposed pattern for this use case:

• +!:uuid:x-1 is the immutable ID of the legal entity responsible for publishing the app (e.g., Adobe or Ford)

• +!:uuid:x-2 is the immutable ID of the legal identity of the brand of the app (e.g., Photoshop or Mustang)

• *!:uuid:x-3 is the immutable ID of the app instance (e.g., an opaque identifier that identifies the user’s unique instance of Adobe Photoshop or a Ford Mustang)

• $agent is the reserved class for a user agent (software code) that will send/receive XDI messages.

So full immutable legal identity of the app instance can be expressed by this type statement

*!:uuid:x-3/$is#/+!:uuid:x-1+!:uuid:x-2$agent

Markus brought up that it does not seem intuitive to use a UUID for a product brand name, e.g., Photoshop. Drummond said that there was no requirement for it to be a UUID; any unique identifier in the namespace of the legal publisher of the app would work. However if the reference is to be persistent, then it should have a ! sign. This means it would be fine to use the following:

*!:uuid:x-3/$is#/+!:uuid:x-1+!Photoshop$agent

Markus was concerned that the name of a product did not seem like it should be in the +space. He suggested the following seemed more intuitive.

*!:uuid:x-3/$is#/+!:uuid:x-1*!:uuid:x-2$agent

Markus explained that you can’t have a legal contract with Excel as a product, only with Microsoft as an organization. So that would suggest that Excel as a product name would fall into the * space. Using names instead of numbers, the pattern would look like this:

+microsoft*excel$agent

If a company did not register a trademark on a product name, it could use a relative XDI name.

+microsoft*_excel$agent

Drummond said that this would constitute an important clarification of the semantics of the + space: that it would only encompass legal entities capable of entering into a legal contract.

We discussed the case of a family or household. As a group of individuals, a family would seem to fall in the + space, however it it not a legal entity like a corporation, only a group of individuals. Does that mean it should be in the * space? The contrast between these two options would come down to a choice between the following examples, both of which show that =drummond and =monique belong to the same family.

=drummond[#family]+!:uuid:x-1
=drummond[#family]*!:uuid:x-1

=monique[#family]+!:uuid:x-1
=monique[#family]*!:uuid:x-1

Drummond boiled it down to this question: should the +space be defined to be only groups of natural persons (which are in the = space), and all other entities be in the * space. Since a contract can only be agreed between natural persons or legal entities representing natural persons, this would make contract law the pre-eminent rationale for these context symbol definitions.

This would also mean that product names would not be in the + space.

Peter noted that a user license or terms of service acceptance is with a corporation, and so any XDI link contract involving a product name must ultimately be rooted in the legal entity responsible for developing/publishing/distributing that product, i.e., in a + identifier. Drummond agreed.

Drummond noted that the alternative is for the +space to apply to any form of group, of which legal entities that can enter into contracts are a subset. In this case, groups of individuals, groups of product instances (as represented by product names), and any other specific group would belong in the + space.

Under this definition, product names would fall into the + space.

However there are two drawbacks to this broader definition of the + space:

1. It is harder to decide what constitutes a specific instance of a group. For example, the Midwest is a group of U.S. states. Should it be +midwest or *midwest?

2. There would not be a bright line that a link contract must be between = and/or + entities. For example, as Markus points out, you can’t enter a link contract with a product, only a company, yet with this definition, product names would fall into the + space.

For these reasons, Drummond agreed with Markus’ proposed refinement of the definition of the + space to apply only to groups of natural persons (whether or not that group is explicitly a separate legal entity). This means the + space does not apply to any other type of entity, including product names. Product names and any other type of entity name that is not a natural person or an entity representing a group of natural persons are in the * space.

NEXT CALL

The next call is next week at the usual time (Monday 10AM PT).