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 Unofficial Telecon Notes: Thursday 2018-06-28

XDI TC Notes

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

Date: Thursday, 28 June 2018 USA
Time: 1:00PM - 2:00PM Pacific Time (20:00-21:00 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.


Markus Sabadello
Joseph Boyle
Drummond Reed


Phil Windley


Update from Identiverse

Markus gave an update from his session "Masterclass on the DID Universal Resolver" at the Identiverse conference in Boston. It was a short visit for him (just one day). He said one of the highlights was Kaliya (Identitywoman) talking on “The Domains of Identity”.

Markus said there was relatively little about SSI (self-sovereign identity). The emphasis was mostly on established identity standards like OAuth, OpenID Connect, and UMA.

Markus said that most people in his session were completely new to DIDs (Decentralized Identifiers), so the concepts were new and somewhat difficult to convey. But the audience, which was 40-50 people, seemed appreciative to learn about this new topic.

Update on Austrian "myIDsafe" project

"myIDsafe" is the temporary working title for a proof-of-concept in Austria involving Raiffeisen Bank International, Uniqa Insurance Group, the Austrian Post, and the notaries' association. Phase 1 of this project has now been completed using the Sovrin ledger and XDI agents.

Markus gave an update on the project. He said that what was unusual about this project was the variety of participants and use cases—a broad mix of different partners playing different roles. Different partners played issuers and verifiers and trust anchors.

One of the use cases was an online marketplace where buyers and sellers want to establish trust peer-to-peer. This involved several different ways to establish trust and also who was using which schemas.

Markus said that the first phase was now completed and the participants were generally happy with it. There were also visits by two guest speakers—Anil John from U.S. DHS S&T and Jamie Smith from Evernym. Planning is now underway for Phase 2.

Markus explained that this project was carried out completely with XDI endpoints and the XDI protocol. It did not use pairwise pseudonymous identifiers and zero-knowledge proofs (as is currently done in the Sovrin protocol); rather these were done with direct sharing of credentials.

Drummond asked about how pairwise pseudonymous DIDs and ZKP credentials could be adapted to XDI. Markus replied that doing pairwise pseudonymous DIDs is relatively straightforward because it is done with $ref and $rep statements. The topic of how XDI could begin using ZKP is coming up later in the agenda.

Markus said that one of the topics that comes up is what attributes or credentials a state authority might issue. He said that some are opposed to that, saying it is dangerous because if the state issues credentials to individuals who control their own private keys, and those keys are weak or compromised, then the credentials might be compromised.

Phil pointed out that the same types of concerns were raised about the Internet itself—that companies could never rely on public infrastructure for business communications—but that is now long behind us. Markus also said that that some people think that the term “self-sovereign identity” means that individuals issue all their own credentials (a common misconception).

Markus said the Austrian E-Government Research Institute is very interested in this topic and has been publishing papers on this area. They recently published a new paper about importing eIDAS attributes into self-sovereign identity credentials.

"Importing National eID attributes into a decentralized IdM System"


Update on DID Auth

The Rebooting-the-Web-of-Trust #6 paper on DID Auth is almost complete. Markus gave an update on his thoughts on DID Auth and XDI. He started by saying that the most generic definition of “DID Auth” is “an identity owner proving control over a DID”. However there are many different forms this can take:

  1. Scanning a QR code on a website.

  2. Using a secure browser session.

  3. Sending signed messages between SSI agents.

The paper now includes 10 example scenarios/flows. However none of them involve an identity provider—there is only the identity owner and the relying party.

Some implementations just use JWT (JSON Web Tokens) so they are very much like OpenID.

Other implementations are using JSON-LD and Linked Data Signatures.

Markus explained that the motivation behind the paper is not to write a spec, but to provide a survey of the different approaches and options for DID Auth.

The paper includes sections talking about how DID Auth can work with OpenID Connect and with FIDO. Markus said it is certainly possible to include some of the protocol flows and data formats already established by OAuth and OpenID Connect. Phil asked and Markus confirmed that if you did this, you could end up with a security token that is interoperable with existing systems that are OAuth and OpenID Connect aware.

Markus said that another topic that kept coming up is how DID Auth relates to verifiable credentials exchange. He said the paper concludes there are 3 options:

  1. You do DID Auth and then switch over into verifiable credentials exchange. This is how the Sovrin protocol works. First you establish a connection and authenticate, tthen you do credential exchange.

  2. The second option is to consider it one protocol that does both. It’s a “proof protocol”, and one of the first proofs you can provide is authentication. But the same protocol can then be used to exchange claims. This is basically how OpenID and uPort work. You have authentication and then simple extensions for claims exchange.

  3. The third option is that DID Auth is just another kind of verifiable credential. A DID Auth credential is simply the simplest and most elemental of credentials—as Markus puts it, the “I am me” credential. Markus is not yet aware of any direct implementation of this approach. The one that comes closest is the Credential Handler API being discussed by the W3C Credentials Community Group. It allows the identity owner to send a self-issued verifiable credential that the identity owner controls a certain public key.

Markus pointed out that the essence of SSI is that an identity owner does not need to rely on an external provider to make a statement about you, but the identity owner can make their own statement. However Markus points out that you can really only make the statement “I am me” in XDI. You cannot make that statement in RDF, because it does not have local root nodes.


Markus said that he expects the paper to be ready within the next few weeks.

Update on CULedger

Markus gave a brief update that implementation of the CULedger platform has begun, and integration of XDI is currently underway. He explained how XDI will initially be used in CULedger to provide permissioning and XDI link contracts to enforce what a node of the CULedger node can or cannot do. In the longer term, XDI messaging and link contracts will be used for negotiating agreements between CUs. He and Drummond will both have more info to share as the CULedger project evolves, as Drummond’s employer Evernym is also a CULedger partner.

Credentials/Proofs and XDI

We ran out of time to discuss the final agenda topic—how the concepts of Verifiable Credentials and Proofs can be modeled in XDI, on which Markus wrote a topic paper for Rebooting-the-Web-of-Trust #4. However we agreed we will make that the primary topic of next week’s call.


The next call will be next week at the usual time (Thursday 1PM PT). The link 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]