PDS/IdH/EDV Discussion - 2019-11-22 Minutes

Hi all,

We had 62 people on the PDS/IdH/EDV Discussion call today! A huge thank
you to Amy Guy, who ended up taking 16 pages of transcription from the
100 minute call (see below). Audio available here:

https://zoom.us/recording/play/ZLCVSudx8bk8B9mXRpDd2C-25bhiy0d3G5T9CK6FbXBfhjrpvrS614xXQ_P43RCV

We were also able to make good progress on the two biggest items that we
needed to get consensus on:

RESOLVED: The communities involved in this discussion have decided to
collaborate on a specification for a foundational layer for secure data
storage (including personal data), specifically data models for storage
and transport, syntax, data at rest protection, CRUD API, access
control, synchronization, and a minimum viable HTTP-based interface
compatible with W3C DIDs/VCs.

RESOLVED: Each community contributing work to the effort can, at any
time, withdraw from the effort and/or continue to work on their draft in
their own community.

We were also narrowing in on a proposal for the input work items, but
failed to get a complete proposal worked out:

PROPOSAL: The Identity Hubs and Encrypted Data Vaults documents will be
used as use case, requirements, and technical input for the
collaborative effort. The DID Comm, UMA, and OAuth2 work will continue
in parallel and is acknowledged as important related work.

We were not able to achieve consensus on where to put the work yet, but
were able to get some thoughts down on that specific topic. We will meet
again on Dec 6th at 1pm ET to continue the discussion. I'll send an
invite out for that soon.

Transcription provided by the Amazing Amy Guy follows:

---------------

DIF, W3C, and Aries Joint Meeting to Discuss Personal Data Stores,
Identity Hubs, and Encrypted Data Vaults

IPR Status: No IPR Policy - Discussion MUST NOT contain IP sensitive items

Minutes for 2019-11-22

Agenda:
https://lists.w3.org/Archives/Public/public-credentials/2019Nov/0037.html

Topics:
1. Background, Level Setting, and Goals
2. Plan for Working Together
3. Target Standards Organization
4. Any Other Business

Organizer: Manu Sporny

Scribe: rhiaro

Present: Manu Sporny, Dave Longley, Jonathan Holt, Dan Burnett, Oliver
Terbu, Rouven Heck (ConsenSys & DIF), Joachim Lohkamp (Jolocom), Tobias
Looker, Amy Guy, Brent Zundel (Evernym), Joe Andrieu, oed (3box),
Michael Herman, Evan Tedesco, Daniel Buchner, Maurice Verheesen
(schluss.org), Stephen Curran (Cloud Compass/BC Gov), Robbie Jones
(ForgeRock), Robert Mitwicki (The Human Colossus), Dmitri Zagidulin,
Markus Sabadello, Kayode Ezike, Victor Grey, Orie Steele (Transmute),
Sam Curren (Sovrin Foundation), Luca Boldrin (Infocert), Tzviya Siegman
(Wiley), Eric Welton, Steve Magennis, Dan Kinsley (Civil), Pelle
Braendgaard (uPort), Kaliya Young (Identity Woman), Mike Varley
(SecureKey), Jonathan Reynolds (Workday), Jack Ramey (Workday), Michael
Dang (Workday), Kim Hamilton Duffy, Eugeniu Rusu (Jolocom), Mina Nagy
Zaki (Jolocom), Sean Baldwin-Stevenson (Jolocom), Christian Lundkvist
(ConsenSys), John Jordan (Province of British Columbia), Adrian Gropper,
Thomas Hardjono (MIT), Peter Ng (Civil), George Aristy (SecureKey), Ed
Zabar (Verif-y), Benjamin Beckmann (Magic Leap), Juan Caballero
(Spherity GmbH, Domi Labs uG), Bill Barnhill (Communitivity), Katryna
Dow(Meeco) , Joel Hartshorn (USAA), Liam Broza (LifeScope)

TOPIC: Background and Level Setting

Manu: what we’re here to do today is to figure out how to work together
on these things being called identity hubs / personal data stores /
encrypted data vaults. We’ll hopefully have a target standards orgs
where we’d like to see the work head towards. It would be good to hear
from folks from the DIF and Aries communities as far as background is
concerned - not opinions, background in general.


I’ll start out, then we’ll hand over.
(Daniel for DIF, Sam for Aries)


There has been activity around personal data stores for a long time
[[In 2010 Kaliya founded a trade association of over 40 companies around
the world trying this]]. There’s the work Solid’s been doing, DIF
identity hubs, data vaults, there are 50 other companies out there with
some form of cloud storage, some more self sovereign than others. Over
the past year or so, couple of years, it’s become pretty clear that we
need to start collaborating more closely together the various
communities, otherwise there’s a danger of duplicating effort and
potentially confusing the market. There have been a couple of attempts
to try to get the communities to work more closely together. There were
a number of us coming from the DIF, Aries and W3C side that got together
at RWOT9 and put together this encrypted data vaults paper
(https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/encrypted-data-vaults.pdf).
The goal was to try to do a survey of all the work in the area and try
to focus on a common foundation that everyone could build on top of. The
goal wasn’t to try to reinvent everything from scratch, it was to try to
figure out the proper layering so at the end of the day the Slid folks
got what they wanted, DIF folks got what they wanted, Aries folks go
what they wanted, etc, and we were all not duplicating effort and
building on a common foundation. That’s where that paper is coming from.
We’ve already had conversations with folks at DIF, hoping to increase
with Aries, and people at W3C on how we can move these things together.
There felt like there was momentum. 3 months ago it felt scattered but
as we’ve had these discussions it feels like momentum has been building
towards trying to work together on a spec that enables everyone. We want
to discuss the state of that today and see if we can move any of that
stuff forward.


Daniel: Manu and I had a conversation a few weeks ago, our goals are
similar to everyone else in the community, I can speak to some of the
DIF and Hub initiative stuff. To represent DIF in general, the
architecture people see is the service endpoint and it’s the primary one
that gets hit. Some of the reasons for that are for scaling up, open web
DMZ traffic is hard. You try not to put as many of those endpoints out
there as you can because it can be difficult, if you have 30 different
types of hubs and things out there it’s a tough problem. We saw hubs as
encrypted stores of data that weren’t empowered, that couldn't have your
keys, but also acted as a relay. There are some subtle differences from
the other efforts, acting as a relay for us meant not only storing data
and making sure people with access can get it or someone they permit,
relaying meant something like if you were another entity, one flow you
might subscribe to is you want to get a credential, everything that goes
into issuing a credential is encrypted messages that get sent to this
thing, they’re routed to the correct place, one of those places might be
some sort of agent that can handle the actual process and has keys and
is empowered and can do signing. The way the DIF folks perceive this
architecture because putting out one thing that doesn’t have a high
degree of trust and making it web scalable tends to be a good pattern
that has repeated itself throughout history. That pub-sub pattern that
can go through this conduit and handle high velocity. At the very bottom
what it has in common with other groups is we want an encrypted conduit
for messaging where the thing itself can’t see the payload data. We want
it to be DID centric. Many of us want replication so you’re not picking
one provider you’re able to have it sync through devices or instances
you run at home. We want a permission model, capabilities whatever that
allows for people to share in privacy preserving secure ways with other
individuals even if the hub itself doesn't have awareness of where data
is being transferred. I think the underlying approach of DIF is the
underlying topology, this concept of pubsubbing for flows and tasks. We
want to generalize those things and leave other things like more
empowered services as things that are routed to.


Sam: From the DIF perspective I’ve been involved a long time, and as the
concept of agents evolved first in the Indy community that’s now Aries,
having a common DID based communication layer would be incredibly
valuable. We’ve been calling it DIDComm, we’re talking about expanding
that. Daniel and I have long been talking about making sure we can talk
at the basic level. In Aries we’re less concerned about storage and more
about being the empowered agent that is issuing credentials and doing
things on behalf of the entity for which it has a fiduciary
responsibility. There’s a non overlap in the desire to be storage
centric. There is a heavy desire to speak the same storage protocol
underneath so we can interact with storage providers. The third area is
the topology stuff, open questions, a variety of strategies for getting
messages to agents including things like cell phones that are frequently
not online. The three areas that the two efforts address are the storage
which DIF hubs addresses and aries agents do not; the active issuing
credentials etc which is in the Aries camp, and the message routing
which there are still different schools of thought and opinions on.
There was a paper written by Daniel H and Daniel B called Rhythm and
Melody Better Together which describes some aspects of interaction
between agents and DIF hubs. Some of those concepts describe squarely
the interaction between the agent and personal data store in general.
There’s not an Aries interest in making hubs look like agents, the
primary interest is the standardised communication layer built on top of
DIDs and DID docs.


Rouven: An observation over the last 2.5 years is we had lots of these
conversations with Sam and Daniel, where we used one WG in DIF to
harmonise that view. What you heard was the result over a longer period
of time, communities come and learn and bring this back. DIF a lot of
IIW conversations happen, and at the last RWOT was a great place to have
these cross community things. We’d love to offer this more regular
conversation at DIF is a neutral place, I know this may be
controversial. A lot of past critiques like membership and transparency
have been addressed. The DIF steering committee has agreed to address a
lot of these concerns in terms of openness. At least the conversation,
not necessarily everything, to continue what we started with some of the
projects. The connection Sam brought up, not just about the storage
piece but also about DIDComm, there’s a lot of work happening in Aries
and DIF to bring DIDComm together and establish an open invitation to
the community that it might be the right place to continue this.


Manu: What’s been outlined is, there’s a lot of work that needs to
happen, and clearly everyone wants to collaborate with one another to
make sure that work happens. The thing we’re discussing today is a
little more focused. It is purely about the storage layer, it’s not
about DIDComm, not about architectural layering or network topology. We
all need to be very aware of what each community wants to see so that
these lower layers enable the upper layers, but I want to try and focus
the discussion about working together. I think a lot of good things have
happened at DIF and in the Aries community and those communities
continue to work on things like DIDComm and Identity Hubs and getting
that stuff working together. What i’m hoping we get to today is some
common base storage layer. Sam I heard you say we’re more interested in
the higher level stuff and not as interested in the lower level stuff
but clearly we’d want to use the lower level stuff if it’s standardised.
Daniel I heard you say the Identity Hubs stuff, we’re designing it in
this pubsub way because of concerns about scalability and routing and
that kind of stuff and we have some very higher level concerns but if
there was a lower storage layer that you could reuse that would probably
make you happy. The W3C space there are a couple of other orgs that are
trying to figure out how does data portability work, I store my VC
somewhere, how do I make sure I can move it from A to B in the simplest
way possible. All of this is pointing to some encrypted in transit and
at rest storage protocol that is foundational across these various
communities that can then if done correctly achieve all the use cases we
just heard from Daniel and Sam. The other thing that’s important is that
if we’re all going to work on this together we need to have an idea of
where it’s headed, which means standards setting organisation IPR and
all that kind of thing.


There are 4 things on the agenda to see if we agree on. One is the
specific focussed thing that we’re going to work on. The second thing is
how this impacts the various communities working on these things, The
third thing is what kind of input, if we agree to work on something, are
we going to take into that thing. Finally, the hardest thing, where do
we actually house the work. To go out on a limb, after talking with
folks from DIF and Aries and W3C I’m going to try and scope the
discussion to basically we all want a foundational layer for personal
data stores, that’s clear. Specifically we need to at least settle on
the data model and the syntax and a minimal viable protocol. I’ve heard
that HTTP can’t be the only protocol, we want this work over bluetooth
and other types of protocols, but we need to pick somewhere to start.
I’m going to put a proposal into the chat to get feedback. We’re looking
for people to have principled objection against the proposal like that
is totally the wrong place to start or I don’t think that is going to
help us come to a foundational agreement. Then it’s up to open discussion.


Orie: It sounds like you’re triangulating what I wanted to discuss.
What’s the order of operations that we can agree on and which area of
location are we gonna be able to come to an agreement first. I care the
most about that we have as a community some place we have these
conversations with the necessary stakeholders. What I really care about
is there’s some place that the stakeholders in each of these communities
have a regular venue to communicate about what they’re doing. Manu you
have a different approach where you’d like to agree to discuss the
storage layer first and then the location. That might be a better
approach I don’t know. My primary desire is to have these key
stakeholders in some kind of regular location where we can continue to
drive alignment by having everyone at the table.


Manu: The reason I’m proposing we figure out what the work item is is
because if we have a different idea on what the work item is it’s a
different group of people at the table What could easily happen is we
all want to collaborate with each other and we haven’t been doing it to
date, it’s been in these various orgs and that’s because the scope is so
big. If we can narrow the scope down to something new all see as a good
first step that clarifies who needs to be involved and where the work
can happen. That’s why I want to focus on the work item and that will
help us understand who needs to be at the stable.


Adrian: Can you define personal data store cos it sounds like it’s a
scoping down that I would not agree with depending on what you mean by
personal.


Manu: a place to put data that you have control over. Being loose with
the language, we could spend the rest of the call on ontologies..


Sam: One of the ways we could narrow the scope is to focus on the
storage protocols and leave all the transport etc considerations over to
DIDComm which should include all of the concerns of this within its
scope. Not that that work is finished but it puts the conversation into
how we securely communicate based on DIDs. If it’s related to data
stores that narrows the scope a bit.


Johnathan Holt: I think just to, I’m concerned about the initial focus
being on the data stores and how we do the encryption and how we make it
open source and accessible vs really defining the access control.
Looking at my dropbox, my google, my icloud account, I think my
onepassword, behind the scenes they use different underlying
technologies, but I can access to them and I can grant access is the key
thing. The concern about the low level storage, less important than how
we facilitate access control.


Robert: To ask if when we are talking about data storage do we also take
into consideration the data structure and data layer in the storage,
this is what we try to do in semantic working group in hyperledger is
define this kind of data structure, even if we have decentralised data
storage and personal data store around the agents and users will be able
to use them properly means that if I’m asking someone to provide me a
driving license i  can rely on the data structure I will get from them
and having this unified data language. Is it outside of the scope?


Manu: you’re talking about semantics, it’s outside of the scope of what
we’re talking about. Trying to narrow the scope down, what you’re
wanting to do could be layered on top of what we’re talking about but
we’re drawing a bright line between semantics and just storage.


Christopher A: On the scope I’m hoping that we don’t get in the way of
more sharded distributed solutions rather than stores on things like AWS
or etc but solution spaces where the stores are distributed in some
fashion. I’m also hoping that in scope is a more capabilities oriented
access control using cryptography, there are ways to use the same crypto
that we’re using for encryption to also do the access.


Bill Barnhill: Just stating approval of the idea of focussing on storage
protocols and being transport agnostic as long as we can support both
synchronous and async transports.


Daniel B: The biggest things for me are we have an encrypted object. We
can get the Hubs stuff easily we can just accept that. Baking some kind
of capability into the actual spec, means of syncing, maybe not only oen
exact prescribed one, but you could store the objects in whatever
underlying data store you want and facilitate getting to the correct
state by transporting the objects. That gives you the portability that
John was trying to highlight, say here’s my other replica, you’re
porting the data. Everything else Hubs does is completely application
layer and business logic goes on top and is not ins cope.


Adrian: I support the scoping out of semantics that you suggested but I
don’t quite understand how we do what johnny says which is just
authorization and merge that with a capabilities model without having
some demarcation or idea of the relationship between the semantics and
the capabilities that come with the auth stuff.


Manu: this is great, we’re getting feedback on what folks would like to
see and where to focus. I forgot one thing - we do have some proposals
and working tech that we’re working from. Nobody should feel this is a
greenfield exercise. I would like x and y to be considered is relevant,
but there is a desire not to work on things that have been incubated for
a while and have working code behind them. The biggest disconnect that I
may be seeing is the focus on protocol first and forget about storage,
vs the focus on storage and a protocol for that. I may be mishearing
some people on that. None of the proposals on the table are asserting
that you have to use one specific protocol, we’re trying to be agnostic
there. For those that are concerned it’ll be one protocol vs the other,
I haven’t heard anyone propose that we lock one protocol down, that you
have to use HTTP or DIDComm, I haven’t heard that suggested. I think
that proposal has no chance of surviving. Same thing with authz and
sync. I don’t think anyone has suggested that here’s one way way to
synchronize and there’s only one way this early in the process. Same
with authz, people would like to see some kind of OCAP/ZCAP model, but
if we say there’s only one way that proposal would end up failing.
What’s being proposed is let’s make these things pluggable. We need to
focus on one vertical, we have to implement something, but that doesn’t
mean we should preclude the use of DIDComm, master-master replication,
ZCAPs, OAuth2, those kinds of thing. The design should enable all those
things to happen. One of the things that amce out of the rwot9 paper was
allowing flexibility in those ways.


Thomas Hardjano: Data at rest protection, includes a lot of interesting
things including homomorphic encryption. Secure transport, data on the
move, access control, permissions, authorization, the fourth one is
interesting because what I’ve seen looking at the evolution of identify
frameworks such as OIX, us engineers would love to do amazing stuff but
when it comes to personal data some overarching regulation might come in
that technically you can do it but legally ou’re not allowed to do it.
Maybe a discussion on these should feed into the architecture discussions.


Joe A: I like the list. There’s something I haven’t heard - what
operations against the data in the data store are allowed? Which would
include thing slike trying to query. There maybe more sophisticated
operations. We need to deal with CRUD> They should be in the spec,
whether or not there’s an extensible way to perform them and how we
manage it. Just with Thomas’ four we’re missing the ability to do
something with the data that would be good to standardize.


Sam: To clarify what we call DIDComm is an effort to provide transport
agnostic communication secured by information ina  DID doc. It’s
ongoing. If we do not fill needs that motivate someone to go a different
way we’d like to hear about them so we can solve the problem in as
fundamental way as possible.


Daniel B: Wrt querying, I know you do encrypted indexing with EDV and
we’re like well some metadata could be allowed, adding a tag in
plaintext, the best way to approach this is we remove querying from the
scope? We can sync objects, we know the relationships, one object is a
change of another object and that’s all we know, if we can keep it to
that level we can avoid a lot of complexity that could be layered on
after the base spec. Willing to entertain?


Tobias L: To Joe’s point about operations. One conversation we had at
RWOT when writing the paper was framing it in terms of responsibilities
between the storage provider and the data going into storage. Having
that conversation helped us. Please review that appear. That helped us
inspire a lot of work around the design and separation of responsibilities.


Joe A: Daniel, you made my point, the question of what is in scope of
the spec is in scope for the charter of whatever we’re going to do
together. You made a case for queries being out of scope, that should be
decided by the collaboration mechanism we’re putting together. THat
should be included in what we try to figure out.


Dmitri Z: I wanted to argue the point about queries being in scope in
the sense of if we don’t include them in our syncing architecture we’ll
regret it later. But this is getting lost in the details where we should
be focusing on where can we talk about this and can we agree at all.


Manu: I agree. We’re 15 mins to the top of the hour. Folks okay if we
pus another 15 to 30 mins?


I heard a number of people agreeing with THomas’ list. If we focus on
data at rest protection, a secure transport protocol, access control to
the objects, I heard good buy-in for that. The legal framework is
nuclear, IETF and W3C avoid things like that it’s a totally different
layer. I’m hearing a lot of people agree.. Or nobody disagree. I’m going
to rework the first proposal to see if that’s what we can focus on.


Kim: using Thomas’ framework is fine with me.


 Manu: If you want to rework the proposal in the chat channel just
rework it and put it in.


PROPOSAL: The communities involved in this discussion have decided to
collaborate on a specification for a foundational layer for personal
data stores, specifically a data model, syntax, data at rest protection,
CRUD API, secure transport protocol, access control, and minimum viable
HTTP-based protocol.


Adrian: I don’t understand or may object to data at rest protection as
opposed to access control. I don’t want to tie the storage too tightly
to the authz server as an agent of the data subject. I don’t object to
the principle but I don’t think it has to be a MUST. Unencrypted data in
the store should be a first class item.


Manu: That would be an excellent thing to discuss if we can get the
communities together. The proposals are not a hardline stance on
absolutely everything, just to get consensus to get people together. If
it’s in the list it means we’re working on it, doesn’t mean it’s
absolute. It means we’re going to talk about how we’re going to talk
about how we’re going to do data at rest protection.


Adrian: I will hold off, but it doesn’t entirely make sense. But we
don’t have to argue this here.


Jonathan Holt: Just the last work. HTTP is robust we all use it, we use
it in IPFS, everyone knows how to write for it, but it doesn’t need to
be the protocol, it could be the interface to data stores behind the scenes.


Edit by jonathan holt:  PROPOSAL: The communities involved in this
discussion have decided to collaborate on a specification for a
foundational layer for personal data stores, specifically a data model,
syntax, data at rest protection, CRUD API, secure transport protocol,
access control, and minimum viable HTTP-based interface.


Brent: as attempts were made to narrow the conversation I thought we
were talking only about secure storage and now we’ve expanded it again
to pull in transport. I don’t know that I.. maybe they all belong
together we want to talk about them all in one place but it feels like
the scope has expanded.


JoeA: I want to endorse that. A general secure transport protocol seems
out of scope but how you get data in and out of this encrypted data
vault needs to be in scope.


Manu: I agree with Brent and Joe. I started with a broader proposal
because that’s what people were talking about. If we can chop things off
and narrow the scope it’s going to be easier to have the discussion.
Would anyone object to not at least having secure transport protocol in
their understanding that we’re trying to be protocol agnostic but we’re
also trying to pick one protocol to focus on which is an HTTP based
interface.


Johnathan Holt: I think in a lot of the gateway interfaces into ethereum
or bitcoin or ipfs, they’re gateways to the underlying protocol, they
often run over localhost. As much as you can trust your local host I
don’t think we need to bring in the hwol certificate authority into it
as a requirement.


Manu: are you arguing to take secure transport protocol out?


Jonathan H: Yes, we can interface over http and that can be an interface
to the underlying storage over localhost without needing certificates.


Brent: I think the reason the secure transport was put in in the first
place was we agreed on taking the data and putting it someone else. I
changed it to say data models for storage and transport. This is what
the data looks like when we’re going to transport it securely so on the
other end they can interpret it. Not know if it’s necessary for those
data models to be different.


Paste Brent’s proposal - edited PROPOSAL: The communities involved in
this discussion have decided to collaborate on a specification for a
foundational layer for personal data stores, specifically data models
for storage and transport, syntax, data at rest protection, CRUD API,
access control, and minimum viable HTTP-based protocol.




JoeA: secure CRUD API instead of secure transport


REVISED by Adrian and Joe and JohnnyCrunch- edited PROPOSAL: The
communities involved in this discussion have decided to collaborate on a
specification for a foundational layer for secure store of personal
data, specifically data models for storage and transport, syntax, data
at rest protection, CRUD API, access control, and minimum viable
HTTP-based interface.


Adrian: can I suggest store personal data instead of personal data store


Manu: what about enterprise.. We shouldn’t call it personal data store


Adrian: I want to replace the concept of my data with data about me


Manu: would people be okay with that kind of proposal? It’s not hard and
fast, plenty of wiggle room, would you want to participate in a group
working on that stuff?


+1
JoeA: I’m on the queue to back up Adrian’s concern about personal data
store, many of the uses are not personal, they key thing is that they’re
secure.


Manu: Secure data stores?


??: I’d like to see sync mentioned if possible


Manu: a lot of support, I’m loathe to introduce anything new. I agree on
sync.


JoeA: We can bikeshed later


Manu: Adrian would you object to us talk about syncing


Adrian: I want to express the concern that if it’s not done right it’s a
loss of agency on the part of the data subject. As long as that’s
understood.


Manu: Can’t imagine anyone would fight back against that.


REVISED by Adrian and Joe and JohnnyCrunch AND Daniel Buchner- edited
PROPOSAL: The communities involved in this discussion have decided to
collaborate on a specification for a foundational layer for secure store
of personal data, specifically data models for storage and transport,
syntax, data at rest protection, CRUD API, access control,
synchronization, and minimum viable HTTP-based interface.
(Looking forward to more bikeshedding later!)


Robert: To ask a question about the data model, since eventually it
needs to be moved to other provider or storage, and the data model is a
representation of the data structure, we end up in the semantics as
well. Did I get that wrong or is it an important pieces in that layer?


Manu: The current set of proposals on the table is that level of
semantics is important to support but the core data model is not a
linked data data model, no proposal on the table to have semantics in
layer 1 other than the minimum you need to encrypt store and retrieve data.


Daniel B: the sync thing is a security issue and certainly a privacy
issue in the sense that if you can’t know the states, syncing is about
state,s do i have all the things, are they right things in the ride
order, it becomes a question of is it reflective of what it should be.
Crucial to call out how instances of these things should communicate and
come to the same state.


ChristopherA: It was said early on that we wanted to use DIDs for this,
none of the proposals use that, and on the question of DIDs uses a
general self sovereign architecture, do we want to talk about the fact
we want to support that kind of architecture either in the name or in
the proposal.


Manu: I think everyone is making an assumption that it’s self sovereign
data storage to a certain extent and that it would be compatible with
DIDs. I think the record would make that clear. I want to call general
consensus on that first proposal. It’s pointing in a general direction
that allows us to band together and move forward. There are a couple of
other proposals to get to. Unless someone would like to object ot u
shaving consensus on that proposal, loose consensus not hard, does
anyone have any principled objections to the proposal that was made and
the modifications since then?


Everyone is saying yeah let’s talk about sync, let’s make sure it’s DID
based, needs to encapsulate enterprise storage as well not just
personal. Not hearing anyone objecting, that’s good. Gonna move on.


Paste final proposal please someone -
Paste Brent’s proposal REVISED by Adrian and Joe and JohnnyCrunch AND
Daniel Buchner- edited PROPOSAL: The communities involved in this
discussion have decided to collaborate on a specification for a
foundational layer for secure data store (including personal data),
specifically data models for storage and transport, syntax, data at rest
protection, CRUD API, access control, synchronization, and minimum
viable HTTP-based interface compatible with W3C DIDs/VCs.
(Looking forward to more bikeshedding later!)
Plan for Working Together
Manu: In order for the communities to work together there has to be a
balance. We have to all be getting something out of this. The proposal
has to do with the right to walk away with whatever spec they have
contributed and leave. If the work takes a direction that you don’t
agree with. Eg. if Identity Hubs feel like we’re not doing the right
thing from there perspective they are not blocked from walking away.
Hopefully this is fairly simple that everyone agrees to. Any modifications?


PROPOSAL: Each community contributing work to the effort can, at any
time, withdraw from the effort and/or continue to work on their draft in
their own community.


Manu: seeing general buy-in there. The next question is what are the
input docs going to be? I think we have general agreement that the
Identity Hubs folks and the Encrypted Data Vaults folks want to work
together. There are specs and implementations. There’s an open question
about where DIDCOmm fits in. it’s definitely part of the discussion. Do
any of the aries RFCs provide input or do we hold those back to see
where they might fit and then provide input?


Sam: Since IIW we’ve been having conversations about how to broaden the
discussion of DIDComm outside of the aries community. There’s agreement
to establish a DIDCOmm wg at the DIF to start from where aries left off
in order to work towards broader community needs. There’s a small
collection of aries RFCs to start the conversation and will take
whatever form it needs to to move to the DIF.


Manu: Do you feel like we need to explicitly call out DIDComm as input
documents? It feels like it’s going to be a part of the discussion? I’m
wondering if there’s some kind of input document that we can use into
the work from the DIDComm work, or do people feel like that’s necessary?
If we have Identity Hubs and EDV is there a document that we’d want to
put in from the DIDComm world. Daniel is asking what is an input
document, it means putting the text into the combined specification
we’re all going to work on. Eg. EDV is in respec format we can put that
in there, the Identity Hubs spec I believe is under W3C IPR so we can
put sections of that in there. Are there DIDComm-y things we can do that
with as well?


Rouven: There will be input sounds like a one off activity but there’s a
lot of evolution happening in all these aspects, how do we keep this
input on a constant basis, DIDComm is evolving, a one-off input vs an
ongoing influence.


Kim: Clarifying what you meant: are we suggesting DIDComm is integral to
this discussion? I think is not correct. I thought we can work with
DIDComm but it’s not core.


Manu: The DIDComm work is happening and will continue. This work will
pay attention to it, and there may be a point in the future that they
converge or DIDComm is pulled in but the expectation is that’s going to
happen in the future. Anyone thinks that needs to happen immediately? Or
can we establish communication with the DIDComm work to make sure
efforts are aligned? We have to have some document as the starting
point. Suggestion that it’s some combination of Identity Hubs and EDV.
We’re clearly going to take DIDComm into consideration but I don’t know
if there’s a specific document we should pull in now or wait and it will
become clear how DIDComm interplays.


Adrian: I worry a lot about DIDComm being not explicitly considered
upfront as being either out of scope or part of the vocabulary. It’s
very hard for me to follow what’s going on here as well as DIDComm. It
scares me. DIDComm scares me. That doesn’t mean it’s about me, if it
scares me we need to deal with DIDComm up front rather than pushing it
off to a parallel projecting.


John Jordan: I was going to say the opposite, these things need evolve
in parallel in awareness of each other in this time. I don’t think we’re
at a level of understanding to start aggregating things. I believe they
are separate but related concerns.


Manu: I agree. Two options: DIDComm runs in parallel and stay very aware
of where it’s going, and at some point they may or may not converge, but
we don’t do it upfront. I’m seeing a lot of +1s to John’s point. Here’s
a more concrete proposal. The question is what do we use as input
documents; what defines use cases, requirements, specific technical input.


PROPOSAL: The Identity Hubs and Encrypted Data Vaults documents will be
used as use case, requirements, and technical input for the
collaborative effort. The DID Comm work will continue in parallel in DIF
and is acknowledged as important related work.


Manu: Thoughts? Modifications?


Adrian: I would like to add the UMA spec as an important related
document (and a third “input document”, if IPR allows). It is pure
protocol, brings in a lot of fairly well-specified language.


Manu: What’s the IPR around UMA?


Adrian: We’ll settle that somewhere else.


Manu: Feeling uneasy, this is the first time it’s come up as input.


Adrian: The reason I’m insistent is otherwise we’re going to invent a
whole new jargon and waste a huge amount of time in the definitional
stage for no reason. I don’t think there’s an IPR problem.


Manu: Input document means we’re going to copy and paste swathes of the
document into the collaborative document. What you’re saying is we need
to align on technology.


Adrian: not a parallel thing, we should align and if it’s an IPR issue
we should deal with it because there’s work here on OAuth2.1 and OAuth3
and it’d be nuts not to acknowledge that from the beginning


JoeA: Adrian I agree UMA is really important, I was involved, what we’re
talking about is these input documents are not going to be further
developed on their own, they’re coming into this and becoming this. We
don’t have the position do that with UMA, it’s not going to become this.


Manu: Seeing -1s to using it as an “input document”. I think Adrian what
you’re saying is we need to be very aware of UMA and attempt to align
with language and flows that they’re doing, but you’re not saying we
need to copy and paste large sections of UMA into our joint work item.


Adrian: Right. We want to adopt the terminology, not the text. UMA has
spent a great deal of time working on the self-sovereign principles as
part of the 2.0 stuff. Given that it is a self-sovereign protocol,
capable of self sovereign agency, I just don’t want to reinvent the
terminology.


Kim: I have a proposal, there’s a lot to unpack with these related
efforts. The IP makes me nervous. Can we agree to figure this out
subsequently, what are the related efforts and input documents?


Manu: Would anyone object to going to the top of the hour? There’s one
more proposal, where are we going to put this work.


JoeA: who has the next of these calls? Where are those hosted?


Manu: We need to get to that. Extend 30 mins to figure that out, we
might be close.


Rouven: I’m pushing other things out and we already lost like 15 people,
maybe we’re losing people who want to contribute to this part.


Manu: Okay, 20 minutes. We’ll figure the input documents out..
Target Standards Organization
Manu: sounds like we’re talking about some kind of HTTP Restful type
API. First question is does it go to an SDO or not. The general hope is
that it does. Question is what is the SDO? I proposed W3C. If we pick
W3C it ends up becoming its own CG or a task force under the Credentials
CG, and the target org is W3C. Any other standards setting organisation
would be a better fit?


PROPOSAL: The intent is to eventually standardize the work at W3C under
W3C's Royalty-Free Patent policy. Regular calls will be hosted under the
W3C Credentials Community Group under the aforementioned IPR policy.


Rouven: My impression, I feel DIF might be the right place, at the
moment it’s interesting because we have various communities coming
together and we’re trying to scope things. It might be IETF or W3C that
are the best places to make a standard, but we continue to incubate the
work in DIF which gives us time over the next x months to figure out
more precise scopes to then make a decision of what’s the right place
for formalising these standards.


Manu: Seeing a number of people say IETF. Anyone want to speak?


Adrian: I would support Rouven’s position that it’s going to go into
either W3C or IETF, people that have open standards, but that we can
incubate it somewhere else for the time being as long as we can postpone
that decision while we incubate it in DIF or somewhere else.


ChristopherA: I want to speak to I used to be regularly involved in
IETF, now more W3C. In order for this to move to IETF you’re going to
have area director support, I’ve not seen a lot of area director support
for self sovereign architecture stuff. I’m maybe IETF could be a better
place but it’s pretty much area director decides type of thing so it
can’t become a working group without an area director. Unless someone
has information that I don’t that the area director has changed his
mind, I dunno.


Kim: I’m pinging the other DIF steering committee members. We’ve been
working to open up DIF but because it’s new I’m unclear about what’s
available now vs what we’ve been discussing. There’s a track for the IPR
documents and waivers but I’m not clear whether it’s free and open to
the public like a community group would be?


Rouven: We have, from a structural perspective, DIF is under the JDF
umbrella so we have IPR agreements in place. The different models for
now, we use the membership model, there is a feedback agreement which
allows individuals as well to join. What we agreed yesterday is we want
to move to a more open and inclusive place. DIDComm is the first WG
where we start bringing people in with this model. We have not discussed
the storage and compute place for this, but in principle we agreed we
want to move in this direction. We have the setups there, just need to
agree if that’s the place people want then to execute on it. There are
no structural challenges.


Kim: Do people have to pay for it?


Rouven: At the moment the membership has a fee but individuals can join
with the feedback agreement which is not connected to any cost, similar
to W3C. We have on the agenda for further discussions to revisit
membership fees and all of this stuff to make sure it’s reflected.
People can join with the feedback agreement without any costs. What we
need to flesh out more is what’s the difference of what a member can do
vs what a feedback agreement can do. Core point is similar to W3C,
people can participate. Need to flesh out limitations. We want to be
inclusive and have people join without friction besides signing a CLA.


Manu: is that process already set up? I feel like we’d be testing this
for the very first time on this spec. We’re very concerned about the
royalty free license, that everyone can join and participate. This spec
is not an IETF spec, this is definitely not one. Feels to me like W3C.
I’m wondering why we’re not just putting it onto that track. Are you
saying no this spec isn’t going to W3C or are you saying.. I don’t
understand why we’re not just putting it onto the standard path that
things going to W3C are on. One are we doing this for the first time
with this spec? That’s scary. Two: is absolutely everyone going to be
able to join without cost, are you committing to that? Three: is this
W3C bound or are we saying .. it’s definitely not IETF bound, that’s not
going to fly. So it’s W3C or what else?


Rouven: The person who wrote the CLA wrote the CLA for W3C also wrote
the feedback agreement for JDF. It’s not completely new. We’ve note
executed large amount of people joining with the feedback agreement
only. It’s not an untested agreement. The question about whether
ultimately bound for IETF or W3C, I don’t have a strong opinion, but we
haven’t figured out the scope clearly enough. The conversation we
started today could be over the next 3-6 months until it’s clear which
parts would move in which direction.


Daniel B: I’m not sure what the best SDO is because historically W3C is
not put out server side specs like this in the past with much success.
Nothing has been widely adopted. Is that a reason not to do it? I don’t
know. Not saying it can’t be in W3C. We all have to be a bit weary of
the fact that this is going to ruffle the feathers of some larger
members, this is an existential threat territory. I don’t know how that
would play out but I’d love to get it hardened somewhere else where it’s
going to be easy to run fast where no one can stand in your way and have
this polished thing no matter where we take it we can defend it easier.
That would be a strategic reason.


Tzviya: I would love to discuss Daniel’s point with Manu. Not
representing the AB but a sa member, in terms of IPR and as someone who
worked on a spec outside and brought it in. The IP stuff gets really
sticky that way because you have licensing agreements that exist in one
and when you bring it into W3C everyone has to sign the CLA again. If
you bring it from DIF to W3C you have to take the names off or have
everyone sign the CLA a second time if it comes into W3C< it might
duplicate work.


JoeA: Question for Rouven about emerging DIF policies about individuals;
I understand you can join as an individual and you can participate
without fee if you sign the IPR agreement, but what about purely public
access, someone who wants to sit in on a call or read or listen to a
recording of previous calls?


Rouven: We record most calls but not published. Yesterday we agreed with
the steering committee is to move to way more public contribution of all
the resources. Today the github resources are publicly available. We
have not published minutes. What we need to figure out are technical
operational questions, eg. if we use Slack or certain chats which have
protection and others don’t. That’s organisational to figure out. But
it’s committed to do that.


Kim: In the spirit of pissing off everyone, to the point that W3C might
have large corporate interest, it’s also a concern I’ve heard raised
about every other standards track community in our space. There’s always
one or two corporations. Each community is trying to address. I’ve heard
people make similar claims about other standards bodies. I don’t know
how to do the game theory analysis of what is ultimately in our best
interests.


Manu: Noting the time… we’re clearly not done, we’re going to need
another call. Can we continue the discussion on the mailing list to work
through things. This companies are going to view it as a threat was said
for VCs, it was said for DIDs, the companies that fought it are in the
DIF, they exist everywhere, they’re in IETF. Anywhere we do this, if it
threatens a large company they will fight back and they’re everywhere.
I’m concerned about using that as a decision criteria. The W3C has done
API specs, LDP, AP, questionable on whether you think they’re
successful. I appreciate Rouven, DIF’s willingness to open up and I
think we’re going to have to see where the community lands on this. I
think IETF, being a spec editor, this is not an IETF spec, I don’t know
why people think it is, it’s definitely not. The question is do we
incubate longer at DIF the move it to W3C (or elsewhere).


With that said, we got two proposals done, thank you very much, that’s
progress, we all want to work together on this and the right to walk
away if it doesn’t work.


We haven’t figured out input documents or standards setting org. The
next call after the holidays, first week of December, we’ll focus on
trying to come to closure on those questions. In the man time let’s take
the conversation to the mailing lists. ALL the mailing lists. Cross post.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches