W3C home > Mailing lists > Public > public-credentials@w3.org > March 2017

Proposal for UNHCR demo

From: Joe Andrieu <joe@joeandrieu.com>
Date: Mon, 13 Mar 2017 10:21:48 -0700
Message-Id: <1489425708.465579.909765848.79DC7DD3@webmail.messagingengine.com>
To: Credentials Community Group <public-credentials@w3.org>

Here are my thoughts after our call last week about the RWoT demo.  

The Joram 1.0.0 Engagement Model
currently in draft, is an attempt to describe the human interactions
when a Syrian refugee works his way through Greece, with an eye to
descripting requirements for a self-sovereign identity system. It is an
early step to formally understand how to support UN SDG 16.9. For
simplicity, I'll refer to this as the UNHCR use case.

Perhaps the key challenge in this use case is the lack of technology
owned or controlled by the typical refugee. In the engagement model, we
assume that the stewards--not the refugee--have access to a physical
device connected to the Internet, which is capable of properly accessing
a yet-to-be-defined Distributed Data Store. Conceptually, this is just a
smart phone.

The big question for us: can this engagement model be realized with
verifiable claims? What would VC need to support it?

The immediate question is: can we modify or configure Digital Bazaar's
digital wallet to provide a UNHCR experiential demo at Rebooting Web of
Trust IV in Paris?

To demonstrate Joram  in a credible way, I think there are two keys we'd
need to demonstrate:

1. The use of a QR coded bracelet and pin as the refugee's
   identification and authentication mechanism, enabling the refugee to
   selectively share specific proofs/attributes with stewards.

2. The storing of the digital trail of non-repudiable observations,
   accessible via the authentication and selection mechanism in #2.

And specifically, for the wallet you showed us in our call, I think
we'll need:

3. A change in the mental model of the wallet-device relationship. The
   current wallet software assumes the controller of the device is the
   controller of the wallet. In the UNHCR case, the device is controlled
   by the steward, so linking to a wallet--which is controlled by the
   refugee--should not form a long term permission for control over the
   wallet, but rather provide a mechanism for the transfer of specific
   attributes to the steward's system.

The strawman we've been working with includes a few core assumptions:

1. Steward software adheres to a recognized standard authentication
   ceremony. This ceremony includes having the subject (1) unlock the
   dataset with a pin, (2) manage selective disclosure of the dataset,
   and (3) record the access in the data store with a photo of the
   refugee. In other words, we are trusting the software to act to a
   standard and for stewards to use non-compromised devices.

2. We're ok with access to the underlying datastore being
   provisioned/permissioned based on UN criteria, and are comfortable
   with the UN managing consensus and permissioning of steward
   organizations. We don't need to resolve the question of how to
   implement the engagement model in an open public ledger, because we
   see significant benefit in the UN's role establishing rules of
   governance and monitoring participants for bad behavior.

3. Our mental model for the datastore is not cards in the sense of
   Information Cards or loyalty cards, but rather an accumulated context
   of non-repudiable observations, which can be selectively presented by
   the subject. The key to us is that any participant can write an
   observation about a subject, and the subject controls  which
   attributes are shared with which recipients.

While we are pushing towards a user-driven or self-sovereign approach,
our particular scenario is fine with the role the UN--as a collective
collaborative governing body--establishing who can read/write to the
data store and how bad actors are policed and the resulting dataset is
granularly composable by distinct sharing ceremonies.

Proposal for the demo:

1. Issue participants a bracelet with a unique QR code

2. Associate a photo with that QR code

3. Associate a user-selected PIN with that QR code

4. Create several interactions where the bracelet + PIN + a photo check
   (performed by the steward) authenticate the participant for access to
   services. Ideas for interactions:
    a. entrance to the event

    b. getting food

    c. giving a talk

    d. drink tickets

5. As a bit of theater:

     a. an intake scenario of Joram at the beach, taken to UN intake
        officer, linking the participants experience to Joram
     b. at the end, "accuse" a participant of a transgression, for
        which the history of interactions provides evidence refuting
        their guilt.

I'm not sure how much of that is feasible given the timeframe, but if we
can make a good pass at something like this, it would provide a catalyst
for discussion of best practices when the subject and/or controller of a
claim lacks the technology to manage their own keys, but does have the
moral and legal authority to manage  consent and disclosure.



Joe Andrieu, PMP



Received on Monday, 13 March 2017 17:22:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:34 UTC