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: XDI TC Notes Unofficial Telecon Monday 2016-11-08


XDI TC Notes


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

Date: Tuesday, 8 November 2016 USA
Time: 9:00AM - 10:00AM Pacific Time (17:00-18:30 UTC)


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

Markus Sabadello
Drummond Reed
Joseph Boyle
Les Chasen

NOTES

DIDs and XDI

As work continues on DIDs (decentralized identifiers), let’s discuss how DIDs can be used as identifiers in XDI, and how to handle DID “methods” and DDOs (DID descriptor objects) in XDI registration and discovery processes.


DID Specification Working Draft 04:

https://docs.google.com/document/d/1Z-9jX4PEWtyRFD5fEyyzEnWK_0ir0no1JJLuRu8O9Gs/


Markus' first question was whether we want to replace or enhance the  XDI Core 1.0 specification with the did: identifier type.


Drummond suggests that we add support for DIDs in section 13.6 of Working Draft 02 rather than remove support for the :uuid: or :cid: scheme.


Example XDI identifier with :did: scheme:

=!:did:sov:33ad7beb1abc4a26b89246


Drummond pointed out that a native DID does not have the XDI context symbol, so that metadata needs to be added via a type statement in the DDO. He suggests that we should specify the URI values for the DDO type element that correspond to the XDI context symbols that can be used with a DID. He recommends just establishing a base URI that can be followed by the XDI address of any applicable XDI type. For example, the DDO type statement for a person (and thus an XDI address starting with an =) would be something like:

{

    "type": "http://xdi.oasis-open.org/="

]


The XDI spec would defer to the DID specification for resolution of the DID to a DDO.

We then discussed whether the DDO should be available natively in XDI. Drummond said that is really a matter for the DID spec. Markus pointed out that we could proxy the DID spec's current  JSON-LD format into JXD, but that it would be idea if the DID spec supported JXD natively.

This will require creating a normative definition of JXD, which is a matter of replacing the current normative "XDI quad" serialization in XDI Core 1.0.

XDI Verifiable Claims

There is a lot of momentum at a W3C community to specify “verifiable claims” based on the RDF graph model. Let’s discuss how “verifiable claims” would work in XDI.


Verifiable Claims Task Force:

http://w3c.github.io/vctf/


Example RDF verifiable claim:

{

 "@context": "https://w3id.org/identity/v1",

 "id": "http://example.gov/credentials/3732",

 "type": ["Credential"],

 "name": "TestCredential",

 "issuer": "https://markus.at/#me",

 "issued": "2010-01-01",

 "claim": {

    "id": "https://equalsdrummond.name/",

    "email": "drummond.reed@evernym.com"

 },

 "signature": {

    ...

 }

}


Here is the main corresponding data in XDI statement format. Note how a statement about Drummond’s e-mail address (the “claim”) is placed inside an XDI inner root representing a relationship between Markus and Drummond.


(=markus/=drummond)=drummond<#email>/&/"drummond.reed@evernym.com"

(=markus/=drummond)=drummond<#email><$sig>/&/"..."


Here is a more comprehensive representation in XDI statement format that includes an node representing the claims "package":


(=markus/=drummond)[#credential]@~3732=drummond<#email>/&/"drummond.reed@evernym.com"

(=markus/=drummond)[#credential]@~3732<$sig>/&/"..."

(=markus/=drummond)[#credential]@~3732<$t>/&/"..."


Here is the JXD that represents the first pair of XDI statements above:


[
 {
   "@xdi": {
     "sig": "<$sig>",
     "email": {
       "@id": "<#email>",
       "@type": "@id"
     },
     "=drummond": {
       "@type": "@id"
     }
   },
   "@id": "=markus",
   "=drummond": {
     "@type": "@graph",
     "=drummond": {
       "email": {
         "@value": "drummond.reed@evernym.com",
         "sig": "..."
       }
     }
   }
 }
]

Review XDI Message Format

Markus has some ideas for simplifying the XDI message format as we migrate to JXD.


Current XDI message format:

http://xdi.org/xdi-spec-docbook/xdi/xdi-messaging-1.0/xdi-messaging-1.0-wd04.xml

https://wiki.oasis-open.org/xdi/XdiMessagePatterns


Before discussing this topic, Markus also pointed out that he added standard JXD mappings, as well as JXD examples, to this wiki page:

https://wiki.oasis-open.org/xdi/JsonXdiMapping


Markus then proposed to change the patterns for identifying the sending peer and receiving peer of an XDI message.


Old pattern:

(=markus)/$send/=markus[$msg]*!:uuid:1234         SENDING PEER

=markus[$msg]*!:uuid:1234/$is()/(=drummond)       RECEIVING PEER


Proposed new pattern:

=markus[$msg]*!:uuid:1234/$from/(=markus)         SENDING PEER

=markus[$msg]*!:uuid:1234/$to/(=drummond)         RECEIVING PEER


Markus explained that the rationale behind this change is to have more intuitive keywords for expressing sending and receiving peers ($from and $to), and also to have both pieces of information clearly attached to the XDI entity representing the message, which is important for cryptographically signing and/or encrypting the message.


Les noted that in the proposed new pattern, there is no $send operation anymore, which doesn’t feel right, since every message has to be sent in order have an effect.


While discussing this point, we reviewed an advanced example where an XDI message is sent from an agent to a cloud, and then to another cloud. Using the new pattern, this is expressed using a $send operation as follows:


*agent[$msg]*!:uuid:1234/$from/(*agent)

*agent[$msg]*!:uuid:1234/$to/(=markus)

(*agent[$msg]*!:uuid:1234$do/$send)=markus[$msg]*!:uuid:5678/$from/(=markus)

(*agent[$msg]*!:uuid:1234$do/$send)=markus[$msg]*!:uuid:5678/$to/(=drummond)


While reviewing this, Les’ point now became obvious, since even though two messages are sent, only one $send operation is present. We therefore realized that the initial message by the agent also needs a $send operation, using the following pattern:


/$send/*agent[$msg]*!:uuid:1234

*agent[$msg]*!:uuid:1234/$from/(*agent)

*agent[$msg]*!:uuid:1234/$to/(=markus)

(*agent[$msg]*!:uuid:1234$do/$send)=markus[$msg]*!:uuid:5678/$from/(=markus)

(*agent[$msg]*!:uuid:1234$do/$send)=markus[$msg]*!:uuid:5678/$to/(=drummond)


The first line expresses the sending of the initial message, from the perspective of the originating agent.

Review XDI Link Contract Format

Markus also proposed to change the $do keyword in link contracts, in order to avoid overloading its meaning in messaging and link contracts.


Old pattern:

(=markus/=drummond)$do/$get/=markus<#email>

(=markus/=drummond)($do$if$and/$true){$from}/$is/=drummond

(=markus/=drummond)($do$if$and/$true){$msg}<$sig><$valid>/&/true


Proposed new pattern:

(=markus/=drummond)$contract$do/$get/=markus<#email>

(=markus/=drummond)($contract$if$and/$true){$from}/$is/=drummond

(=markus/=drummond)($contract$if$and/$true){$msg}<$sig><$valid>/&/true


Note that while the “main” keyword to identify link contracts is now $contract, the $do keyword will now be used to identify the branch of the link contract that specifies permissions.


Les felt that the $do keyword was not intuitive here, since the link contract only expresses permissions; no actual operations are executed at this point. Markus thought that $do makes sense here, since the patterns for expressing permissions (in a link contract) mirror exactly the patterns for executing operations (in a message).


As a consequence of this change, the keyword to identify link contract templates will also change from {$do} to {$contract}.


# ACTION ITEM: Everyone review and provide comments by next week’s call

NEXT REGULAR CALL

The next call will be the following week at the usual time (Tuesday 9AM PT). The link to where agenda items can be posted for the next meeting is: https://docs.google.com/document/d/19oDl0lbb56Grehx2a5flZnhrgnua5l8cVvC_dJ8fTXk/edit?usp=sharing




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]