Re: Proposal for UNHCR demo

On 2017-03-13 10:21 AM, Joe Andrieu wrote:
> The Joram 1.0.0 Engagement
> Model https://docs.google.com/document/d/1GLejHAyOGcFZMDH23VpBK5as_474gt1tdYZIWkHm7c0/edit?usp=sharing,
> currently in draft, is an attempt to describe the human interactions
> when a Syrian refugee works his way through Greece,

Awesome. Reading it I got two things very strongly, and how they're 
directly linked:

a) How the steward model uses remote data-store technology to

b) Disentangle a fundamental mis-identification issue (i.e., a refugee 
lying about being someone else, for reasons that seem completely sane, 
ie., fear of death.)

Great work.

Steven



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.
>
> -j
>
> --
> Joe Andrieu, PMP
> joe@joeandrieu.com <mailto:joe@joeandrieu.com>
> +1(805)705-8651
> http://blog.joeandrieu.com
>

Received on Monday, 13 March 2017 19:16:06 UTC