[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Agenda: XDI TC Telecon Friday 10:00 - 11:30AM PT 2015-06-29
Following is the agenda for the unofficial telecon of the XDI TC held on:
Date: Monday, 29 June 2015 USA
Time: 10:00AM - 11:30AM Pacific Time (17:00-18:30 UTC)
THE LINK TO THIS AGENDA AND LIVE MEETING MINUTES IS:
https://docs.google.com/document/d/1t5Mx0ITqJdLwo8wM5GD9lcqehgbgnrhk-k2sERwc7J0/edit
Meeting number: 658 320 206
Meeting password: xdi
Join by phone
1-650-429-3300 Call-in toll number (US/Canada)
1-866-469-3239 Call-in toll-free number (US/Canada)
Access code: 658 320 206
Global call-in numbers | Toll-free calling restrictions
IRC Channel: irc://irc.freenode.net:6667/xdi
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 identity “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.
In the work on secure messaging, the need has arisen to be able to identify:
The legal authority for an app responsible for sending/receiving XDI messages
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 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)
+!:uuid:x-2 is the immutable ID of the legal identity of the brand of the app (e.g., Photoshop)
*!:uuid:x-3 is the immutable ID of the app instance (i.e., the user’s Adobe Photoshop serial number)
$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
On several recent XDI TC as well as XDI2 implementation calls, we have been working on a walkthrough for a "secure, semantic messaging" use case. This combines concepts from the XDI Messaging, XDI Bindings, XDI Policy, and XDI Connections spec. This also introduces the concept of “channels”. Let’s continue to add more details to the walkthrough and answer any questions.
https://wiki.oasis-open.org/xdi/MessagingWalkthrough
The next call is next week at the usual time (Monday 10AM PT).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]