Date   

Indy Contributors Call - Mon, 12/16/2019 #cal-notice

indy@lists.hyperledger.org Calendar <noreply@...>
 

Indy Contributors Call

When:
Monday, 16 December 2019
9:00am to 10:00am
(GMT-07:00) America/Denver

Where:
https://zoom.us/j/615818107

Organizer:
richard.esplin@...

Description:
The Indy Contributors call provides an opportunity to get an update on Indy work, help others understand your contribution, resolve complex challenges, discuss roadmap commitments, and identity cross-team dependencies.

The call rotates between two timezones to give as many contributors as possible the opportunity to participate.

Feel free to add a topic to the meeting agenda. The meeting agenda will be posted here:

https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/615818107
International numbers available: https://zoom.us/u/akZ4IVIpQ


Upcoming Event: Indy Contributors Call - Mon, 12/16/2019 9:00am-10:00am #cal-reminder

indy@lists.hyperledger.org Calendar <indy@...>
 

Reminder: Indy Contributors Call

When: Monday, 16 December 2019, 9:00am to 10:00am, (GMT-07:00) America/Denver

Where:https://zoom.us/j/615818107

View Event

Organizer: Richard Esplin richard.esplin@...

Description: The Indy Contributors call provides an opportunity to get an update on Indy work, help others understand your contribution, resolve complex challenges, discuss roadmap commitments, and identity cross-team dependencies.

The call rotates between two timezones to give as many contributors as possible the opportunity to participate.

Feel free to add a topic to the meeting agenda. The meeting agenda will be posted here:

https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/615818107
International numbers available: https://zoom.us/u/akZ4IVIpQ


IPR action item - update / Re: PDS/IdH/EDV Discussion - 2019-12-06 Minutes

Rouven Heck
 

Hi all,

I would like to provide a brief update around the action item around the IRP question:

Earlier this week the JDF/DIF legal expert provided the details about copyright licenses & patent policy used in DIF as well the specific terms on how DIF materials can be taken to standards bodies. (FYI - for patents, DIF uses the W3C patent policy without alteration.)

I have shared details on Thursday with the W3C leadership team and expect their feedback soon. I'm optimistic that we can turn around any questions quickly next week. I will share further updates as soon as possible. 

Looking forward to removing the outstanding blockers asap so we can start collaborating more closely soon. 

Best,
Rouven


On Fri, Dec 6, 2019 at 5:16 PM Manu Sporny <msporny@...> wrote:
Hi all,

We had around 60 people on the PDS/IdH/EDV Discussion (second call)
today! A huge thank you to Amy Guy and Kaliya Young, who ended up taking
18 pages of transcription from the 90 minute call (see below).

Amy, Kaliya, you are our scribe heroes!

Audio available here:

https://zoom.us/recording/share/BylkqbPxcMO9-Opie8Y3Y2QPyrGwwnqztvRyJVvCqGCwIumekTziMw

We were successful in passing the following resolutions:

RESOLVED: The PDS/IdH/EDV spec would be a joint work item of DIF and W3C
CCG (and anyone else that wants to join, the group is open).

RESOLVED: DIF would host the PDS/IdH/EDV calls, which would be open to
everyone without any fees, with full transcriptions (scribing), audio
recording of calls, and publication of minutes.

RESOLVED: DIF would host the reference implementation and test suite for
PDS/IdH/EDV. The reference implementation is not the standard and is not
the test suite and is not expected to be THE one implementation everyone
should use.

RESOLVED: 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 are acknowledged as important related work that might
influence the direction of the collaborative effort.

Next steps: The IPR policy will need to be agreed to between DIF and
W3C. Rouven has an action item to move that discussion forward. Meetings
will not begin until this is resolved.

Transcription provided by Amy Guy and Kaliya Young follows:

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

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


IPR Status: No IPR Policy - Discussion MUST NOT contain IP sensitive items
Minutes for 2019-12-06
Agenda:
Topics:
 1. Review Current Status
 2. Discuss where the work could happen.
 3. Discuss the IPR regime for the work.
 4. Call times/frequency.
Organizer: Manu Sporny
Scribe: rhiaro and Kaliya
Present: Manu Sporny (Digital Bazaar), Amy Guy, Balazs Nemethi, Jonathan
Holt (TranSendX), Dan Burnett (ConsenSys), Brent Zundel, Tzviya Siegman
(Wiley), Joe Andrieu, Joachim Lohkamp (Jolocom), Rouven Heck
(ConsenSys/DIF), Isaac Patka (Bloom), Troy Ronda (SecureKey), Chad
Peiper (Verif-y), Eve Maler (ForgeRock), Richard Kraaijenhagen, Steve
Magennis, Orie Steele, Dmitri Zagidulin (Digital Bazaar / Solid), Robbie
Jones, Adrian Gropper, Michael Benaudis, Samuel Smith (ConsenSys),
Sumita T. Jonak, Joel Hartshorn, Ed Goode (Microsoft), Kaliya Young
(Identity Woman), David Lehn (Digital Bazaar), Dave Longley (Digital
Bazaar), Lior Margalit, Katryna Dow (Meeco), Jo Vercammen (Meeco), Nancy
Lush, Jan Vereecken (Meeco), Eddie Kago, Victor Grey, Jack Ramey
(Workday), Stuart Freeman, Michael Dang (Workday), Daniel Hardman
(Evernym), Brent Shambaugh, Tobias Looker (Mattr), Justin Bingham
(Janeiro Digital / Solid), Christopher Allen (Blockchain Commons), Evan
Tedesco (Dish Wireless), Ganesh Annan (Digital Bazaar), Sam Curren
(Sovrin Foundation), Snorre Lothar von Gohren Edwin (Diwala), Dietrich
Ayala (Protocol Labs), Eric Welton (Korsimoro)


Manu: Please don’t discuss things that are IP sensitive or patent
related. This call is about how we coordinate the work around data
vaults, identity hubs, etc. No technical details. We’re going to review
current status, primarily we decided what we wanted to work on but
couldn’t decide where the work would happen. This call we’ll try to
drive towards consensus on where the work happens. What IPR policy and
what org. Then we can get call times and frequency. There are 47 (60 at
the height of the call) people here, we’re going to have to be good
about focussing the discussion. Please know that if we ask you to make
your point quickly that you do s because we have a lot of people with
opinions here.


The queue, if you want to talk type q+ in the chat channel (zoom), first
come first served.


Rouven: Setting expectations of us getting to the point where we have a
decision or consensus on something and then finding specific times might
not be the outcome I was expecting giving we have many people from
Europe and asia not joining. We work out options for proposals to then
get feedback outside of the call so we can make sure it’s inclusive and
not just people who could make it to this call.


Manu: what we can do is put proposals forward on the call today and see
if we have agreement on the call and circulate them through the minutes
and get other people providing feedback. We have 50 people, that’s a lot
of input, if we can get consensus on this call I’m fine with circulating
it but everyone wants to see this work move forward sooner than later.
Nobody is trying to exclude anyone but we should try to drive towards
consensus.


Rouven: i know many different companies who can’t make it. I’m not sure
this is sufficiently representative of the orgs who are interested. We
can see where we get to. Even if we have 150 people it’s not necessarily
everyone.


Manu: would like to hear from Rouven on DIF, Sam from Aries.


Manu: we had proposals last time on the work items. Seemed like we had
consensus. We circulated the minutes, nobody objected to those
proposals. We’re proceeding as if those proposals are standing unless
someone raises an objection.


Last time we didn’t get to one proposal that we almost got to completion
on around what the work items would be. Im wondering if we can finish
that off on this call. Start by finishing that off. Then go into some of
the potential proposals. Some are in the top of the document. Tried to
sort it in order. What we can do is maybe once we have the basic
position statements from everyone we can hopefully roll into each
proposal and talking about each proposal. I’ve had a bit of a discussion
with Rouven on the mailing list, there’s been a discussion between Aries
folks and DIF folks and ccg folks in the interim. I think what we’re
here to do today is to get to consensus on where the work happens and
rough outlines on how it happens. That’s where I think things are.


Sam: The position from Aries is not complex. We are interested in using
these and interoperating with them, but they’re not really an
overlapping concern to agents which are the primary work inside of
Aries. We are here and interested, there’s a preference that the
communication protocol use DIDComm as a foundational piece of
communicating securely on top of DIDs. Other than that there’s not a lot
of conflict here.


Rouven: I think there was part of the discussion in the email. It didn’t
reach everyone, it bounced back from some lists . The question which
came up might have been confusing in the last conversation around scope.
I’m just reiterating. There seems to be still clarity required about how
DIDComm, Solid and other pieces will fit together. We might discover
that when we go more into the work, or questions might come up. That’s
why I’m advocating for figuring out some of these things, will help ups
to determine what’s the ideal long term place for standardisation.
Doesn’t mean incubation couldn’t happen now. The second part to
protection, of course all the orgs have similar concerns, trying to
highlight the incentives for everyone who is part of DIF is to focus on
building decentralised identity solutions, high incentive for everyone
who is part of this to make sure it’s moving fast, that’s the
difference. Around policies - legal aspects, I might have not done a
sufficient job last time to say that we are fully aware of the needs for
IPR protection etc. The question which are always coming up are based on
a lack of mutual understanding of the IPR situation. I don’t think we
will solve this in the conversation today. If there are still remaining
concerns that the protection in DIF is not sufficient we should have a
conversation with lawyers to make sure we can remove this. Last, we have
been working on incubating this storage thing since a few years now,
within DIF, so I’m wondering more like the other way around what’s the
reason we would not want to continue the work there, under the
assumption that the legal and IP aspects are fine, and as I mentioned
last time in terms of openness that should not make a difference, we can
provide the same infrastructure.


Christopher A: I want to speak from the CCG perspective as the members
of the CCG and we as a community have created a full standard in VCs, a
now working group which is the DID working group which has been
chartered and begun. Quite a few other initiatives for some time.
There’s a proven track record of dealing with IPR, some people complain
about the difficulty of getting the two groups chartered but we’ve got
better with it. DID was much faster and I think that the social attack
vectors are well understood, and were mitigated very well under w3c
process. My concern about looking through the list of processes and
things from the DIF perspective is that they’re unproven, we don’t have
examples of success with those, it’s too important of a project
especially as it crosses so many different kinds of organizations and
groups that I’m uncomfortable with that sort of IP regime. I really am
firm that I would like to stick with the W3C. Under the CCG is the
lightest of the W3C requirements. Pretty straightforward, we’ve used it
at RWOT (not a w3c meeting), at other types of things. I think that it
can serve well and be a nice entry point for things. I would love to see
DIF continue to work on their process, maybe with some kind of thing
that is more internal to the DIF community, and prove out their ability
to move through to a specification that can become a standard, but I’d
like to see the proof of that before we do it on something big. As far
as the statement that DIF has been working on this longest, I would
definitely say no. Other parties, Solid and IPFS, have been working on
these things for a long time. In my work it has come up and I have some
unique approaches of my own. I worry other people might try to patent
them. That’s why I’m particularly concerned about the patent protection
stuff. We want to work with DIF, DIF has more administrative staff. The
ccg is volunteers. We don’t get paid to chair and go to meetings. DIF
does have paid staff, I’d love their support in making this a successful
effort.


Adrian: I want to express, thanks for putting up the proposals that’s
helpful. My concern is about the scoping of what we’re talking about and
the way the proposals are written that there will be parallel efforts in
DIF, IETF< W3C, my concern is specific to the issue if we’re talking
about a storage protocol, are we doing it with the scope of the alice to
bob problem included or not? I don’t mean to discuss that today, I just
want to express this as a concern up front. It does impact how we plan
to resolve the various proposals.


Daniel B: There’s no IPR difference I could find ?? has assured us based
on trust in him as a good lawyer that this is specifically designed to
not have these issues. I don’t think it’s a problem, I’d like to see
where you claim that in a room with all the lawyers. Please do
substantiate that. Also people saying the data store that has been
around. I might have been the first to work on it in 2012, none of these
things existed at that point. General data store stuff PDS stuff out
there for 20 years, but we’re talking about initiatives. We haven’t done
serious things around that. The universal resolver ran out of DIF and
specs went to w3c. We just published our first ratified spec, for
linking DIDs to domain names. That went very smoothly and quickly.
Invite everyone to comment and feedback. I don’t think I’ve heard as
single point that is substantiated, a lot of conjecture, I’d like people
to substantiate if you’re going to use those reasons.


Drummond: one thing about the IPR - as folks know DIDComm is moving from
Aries over to DIF and we just had the aries connectathon this week, we
spent several hours with the WG charter and reviewing the JDF. the JDF
started because of openid and the need to have a clean way to incubate
standards. It’s a very robust intellectual property platform. It’s very
similar to the w3c process. On that issue, unfortunately I’ve been
working for a long time and DIF is under JDF, the processes would be
equivalent. Doesn’t have the track record but JDF has the track record
if you look back to openid and other orgs have operated under it, it’s
the standard way to handle standards incubation at the linux foundation.
I’d take that off the table and put the question of which community
makes the most sense.


Manu: I want to make sure that what we’re going towards is inclusive of
all these communities. What has failed to date is saying this work is
community x’s work and not community y’s work is not going to work. We
should put forward a proposal to band together. Clearly there are
concerns around IPR. I do agree with Rouven that we’re not going to
solve those today. We’re going to have to defer those. But I think that
gives us plenty of things to agree on still. What i’m going to try to
propose is a joint work item between the various communities. A joint
work item between w3c ccg, DIF and if aries wants to be a part - I’m
hearing sam say we’re interested but it’s a different layer - but we
don’t want to exclude any community. It’s a joint work item. What does
that mean? It means all the communities work together on it. I’m
suggesting that the joint work item is an official w3c ccg work item as
well as an official DIF item. That does make the ipr complicated, not
talk about that now .the gist would be DIF would organise and host the
calls but DIF has to make sure that the calls are open to everyone
without fees, with full transcriptions (scribing), recording of audio
and publication of minutes. That’s primarily to make sure we’re making
the initiative as inclusive as possible and covering IPR concerns. The
other question was around where would implementation and test suites go?
The assertion is that DIF would host it, DIF is more set up to do
reference implementations and test suites than w3c typically does. It
could be done in the ccg but DIF wants to head that work up so why not
ensure that that happens. As far as IPR, I really don’t want us to
rathole on the IPR discussion. There is a clean choice we could make
today. I will very briefly highlight it but let’s pleass not focus on
it. Let’s push that off and see if we can create agreements around joint
work items.


If we were to choose the w3c ipr policy and ensure everyone that
participates in the group is a w3c member i think that would take all
the ipr concerns off the table. The work still happens at DIF but under
the w3c ipr policy instead of the DIF IPR policy. If it’s confusing, it
is, there are subtle differences people are asserting exist and if we
took that route we can make everyone happy. The fallback to the IPR
discussion is okay we can’t figure that out which means we need to get
all the lawyers in the same room. That will delay the start of the work
but if that is all we can agree to then we’re all going to have to do
that to see if a DIF transition from w3c or a DIF transition to IETF, is
going to have any kind of issue. Based on assertions by Rouven and
Daniel and Drummond there shouldn’t be an issue. If there isn’t that’s
great. But if there is an issue we need to deal with it.


Going back to the potential proposals, i’d like to see, I’m going from
the top to the bottom. The first is to see if we can agree that the work
is a joint work item between DIF and CCG. if we can’t do that there’s
nothing to talk about here. I’m hoping we can agree to come together.
The second proposals would be DIF would host the calls, ensuring they’re
open to everyone without fees, full transcriptions, audio and minutes.
The third is that DIF would host the reference implementations. Then we
can talk about the fourth and fifth later.


Rouven: I missed what you said at the end. If we can’t agree on this we
all go our own paths? If we do not have a joint one there’s no other way
forward? There’s not an option that it can’t be in DIF?


Manu: I think if the negotiations are going to fall apart; everyone will
go back on their own thing.


Rouven: that’s not where I thought where we are.


Manu: I hope we are all going to come together but if we don’t that’s
the outcome.


Rouven: coming together can be more than the compromise of a joint one.
There are clear benefits of a joint one. Okay nobody needs to give up
something, we work together. I’m not sure it helps us to make it simple
for people to join or more complicated. I’m worried about the IPR
assertions. What we want to achieve is to have a place where we can
incubate as fast as we want and can. From there, during that time where
we work on the definition and the storage part and the didcomm part and
other pieces, then decide now we have formed a concrete understanding of
the specific work items that need to move towards standardisation that
we have a very open path forward. Starting in the ccg assumes it will
need to w3c. That’s something based on the conversations I have not
perceived that this is a given. There are a lot of people who do not
believe the standardisation of the hubs needs or should be in w3c. It
comes with this assumption with that path, even with the w3c ipr would
put us there. The reason JDF started and the lawyers were fully aware of
w3c, started in JDF to build this place which apparently is even more
rigid which gives us all the options later to move to IETF, W3C or
continue incubating to a spec within DIF. the range is more open. I’m
not yet convinced that this compromise is the best.


Jonathan Holt: w3c does come with some baggage. It goes back to the
origins of the web. I love Tim but the ability to spin up a computer at
your desk and be a node on the internet but what it turns out is that
you can’t run that node 24/7. A lot of our data lives in data centers
not owned by me. I’m a bit of a libertarian in that I really believe in
data democratisation and self sovereign identity where i can create an
identity with a random number and I have control over it. I have
companies involved in this space and want to protect that IPR but i’m
still a libertarian at heart where i want to have that radical
disintermediation. We have an opportunity to re-architect to be self
sovereign focussed.


Justin B: I’m a member of the Solid editorial team with Dmitri and some
others. I want to say that interested in collaborating and participating
in this. I look forward to working with you. This is my first call.
Trying to get up to speed from the last call. Will try to study for the
next one.


Manu: I heard Rouven say it would help everyone to understand exactly
what we’re standardising before we put these proposals forward. I’m
concerned that talking about that may derail things because it’s more
specific than the general agreements. I’m trying to get people to agree
on generalities then get more specific. Would you object to us starting
general and trying to get specific or do you want to see that specific
thing nailed down?


Rouven: My expectation is not that we will solve this detail today
anyway. I think my assumption is based on this space is so early. We’re
still learning fundamentally new things. DIDs and VCs are way more ahead
than many other pieces. Based on the conversations we have in different
places like IIW we’re still forming our mental model on many of these
pieces. Therefore my perception is bringing these things or keeping them
closely connected and have a very interaction and discussion with
didcomm and how we store things, there’s a lot of dependencies and for
us to flesh out a nice clean stack will take some time, not two or three
calls but we need to better understand what didcomm will look like, so
incubating these things together in an open space where we don’t need to
worry about ipr because we are protected but gives us all paths forward
is for me not to solve this in the call, we can stay high level, but i’m
just arguing for a continuous conversation in more detail to have a
sharper understanding of how the pieces work together.


Manu: let me start general and get specifici eventually. We will get
there. The first proposal is 1.


PROPOSAL 1: The PDS/IdH/EDV spec would be a joint work item of DIF and
W3C CCG.
00:53:21        Kaliya Identity Woman:        +1
00:53:21        Dave Longley:        +1
00:53:22        Rouven Heck:        -1
00:53:23        jonnycrunch:        IEEE?
00:53:26        Michael Benaudis - Internet Identity Card:        +1
00:53:27        sumita:        +1
00:53:27        Dmitri Zagidulin:        +1
00:53:27        Joe:        +1
00:53:30        ET:        +1
00:53:31        Dan Burnett:        +1
00:53:32        Manu Sporny (Digital Bazaar):        +1
00:53:40        Adrian Gropper:        +1
00:53:43        Joachim Lohkamp (Jolocom):        +1
00:53:50        Joel Hartshorn:        +1
00:53:51        BalazsN:        -1
00:53:54        Joe:        Yes. Of course
00:53:54        Kaliya Identity Woman:        I think it is so easy to
join the W3C CCG to be “under” that IPR
00:53:55        Christopher Allen:        +1
00:53:58        Eve Maler (ForgeRock):        +1
00:54:19        jonnycrunch:        -1
00:54:21        Eddie Kago:        +1
00:55:03        Daniel Buchner:        ~ +1
00:55:03        Orie (Transmute):        +1
00:55:07        Tobias Looker:        +1
00:55:10        Troy Ronda:        +1
00:55:12        Stuart Freeman:        +1
00:55:42        Ken Ebert:        +1
00:55:49        katrynadow:        +1 KD +1 Jo V +1 Jan V
00:56:24        Rouven Heck:        +1 for collaboration: not sure what
joint work item mean in this proposal


Daniel B??: could the two groups come together later and decide to take
it to IETF?


Manu: yes


Rouven: I made my point, it’s not a neutral place for pushing it forward
because we already imply with the IPR for w3c


Manu: it’s a joint work item which means the w3c ccg says we will
contribute and DIF says we will contribute. Where the calls are hosted
is at DIF. we haven’t talked about IPR yet. Do the two communities want
to work together?


Rouven: I misunderstood. Cooperation is good.


Balazs: Yes, I also misunderstood.


Jonathan H: the fact we’re all on a phone call today is that these
communities are coming together. We all have different hats and belong
to different communities. I participate in aries and w3c and IEEE. we
wear different hats. My point is that standards imply standards body.
But if we can create the standard and get it ratified in different
bodies then we have a decentralised solution. We should be eating our
own dogfood.


Manu: how would you modify the proposal?


Jonathan H: we need community input. There (??) we have a decentralised
group of physicians with different boards, who have different
requirements but we come together to collaborate but we also have
community input so our boards are overseen so we’re doing what’s in best
interest of the public. What we have now is companies coming together
competing for customers in a multibillion dollar industry and we’re
slicing up the pie for ownership by standards bodies. We don’t have
sufficient oversight, it’s going to need to be more board than w3c and
DIF. a lot of work has been incubated but there are others that should
be brought to the table to make sure we are doing the right thing for
everyone.


Manu: it’s an open group, anyone can join, we just need to know where
we're going to meet every week.


Jonathan H: this wouldn’t delay how we have oversight. What we settle on
in this group is then brought back and ratified in in the different
communities to get their buy in.


Manu: would you object philosophically to us saying this is at least a
joint work item between DIF and the CCG.. among others.


Rouven: what it means a joint work item?


Manu: all this proposal is about is collaboration. Proposal 1 we agree.


Brent: Look forward to the unravelling of the ramifications of the
proposal we just accepted. We used very specific words that Rouven was
trying to get clarity on that i think are going to mean things that
people didn’t think they meant.


Rouven: what brent said


Adrian: I want to clarify that PDS/IdH/EDV is the name and the calls and
minutes will be in one place? All we just decided is on the name of
something called PDS/IdH/EDV?


Manu: what we’ve decided is to work together on that thing. But we still
need to define what that thing is.


PROPOSAL 2: DIF would host the PDS/IdH/EDV calls, which would be open to
everyone without any fees, with full transcriptions (scribing), audio
recording of calls, and publication of minutes.


01:02:24        Daniel Buchner:        +1
01:02:28        Joachim Lohkamp (Jolocom):        +1
01:02:29        ET:        +1
01:02:29        Manu Sporny (Digital Bazaar):        +1
01:02:31        Joel Hartshorn:        +1
01:02:32        Orie (Transmute):        =1
01:02:33        Dmitri Zagidulin:        +1
01:02:34        Orie (Transmute):        +1
01:02:34        Ganesh Annan:        +1
01:02:36        Dave Longley:        +1
01:02:38        BalazsN:        +1
01:02:38        Troy Ronda:        +1
01:02:39        Stuart Freeman:        +1
01:02:40        Tobias Looker:        +1
01:02:40        Eve Maler (ForgeRock):        +1
01:02:41        justinwb:        +1
01:02:42        Ken Ebert:        +1
01:02:43        Joe:        +1
01:02:44        Brent Zundel:        +1
01:02:44        Adrian Gropper:        +1
01:02:47        jonnycrunch:        q+
01:02:52        Dan Burnett:        +1
01:02:53        katrynadow:        +1 KD +1 Jo +1 Jan


Jonathan H: what happens if DIF goes away? Who has control? Begs for a
decentralised solution. I’m prone to using IPFS myself.


Rouven: DIF is part of JDF which is part of Linux Foundation. There’s
safeguards.


Jonathan H: just make sure policies are in place for long term data
retrieval.


Manu: all the orgs we are considering have that. Calling that passed.


Manu: next proposal up #3


01:04:25        Manu Sporny (Digital Bazaar):        PROPOSAL 3: DIF
would host the reference implementation and test suite for PDS/IdH/EDV.
01:04:33        Daniel Buchner:        +1
01:04:35        Rouven Heck:        +1
01:04:40        Eddie Kago:        +1
01:04:41        Dave Longley:        +1
01:04:43        Orie (Transmute):        +1
01:04:46        Joachim Lohkamp (Jolocom):        +1
01:04:48        Adrian Gropper:        +1
01:04:49        Manu Sporny (Digital Bazaar):        +1
01:04:49        Ganesh Annan:        +1
01:04:49        Joe:        +1
01:04:51        Dmitri Zagidulin:        +1
01:04:52        Dan Burnett:        +1
01:04:53        Troy Ronda:        +1
01:04:55        BalazsN:        +1
01:04:57        Tobias Looker:        +1
01:05:00        Christopher Allen:        +1
01:05:00        ET:        +1
01:05:01        Joel Hartshorn:        +1
01:05:02        Daniel Hardman:        0
01:05:04        Daniel Hardman:        -1
01:05:08        Ken Ebert:        +1


If DIF members want to post an implementation the test suite would be
hosted at DIF
Getting votes…


Daniel H: not opposed but would like to get more clarity before +1
Manu: not clear about full scope


Daniel : Don’t want there to be an open source code base that every one
should use. I want it to be a ‘toy’ model representation not something
we are trying to get the world to build upon.


Manu: I think fundamentally what happens with those reference
implementations - forprofit companies go build something way better.  …
Things will naturally happen this way daniel not sure we can predetermine.


Daniel B: muffled…didn’t object.


Manu: Daniel I heard you say you don’t object. Looking to you with this
proposal would you philosophically object.


Daniel H: Concern heard and worried about announcing it. But will keep
raising until concerns heard.


Christopher A: the reference implementation is not the standard and is
not the test suite - would like have it amended to the statement.  Some
people don’t understand the differnece it needs to be explicit
(Something like this happened with SSL where difference was not
understood).


Manu: working on integrating feedback.


PROPOSAL 3: DIF would host the reference implementation and test suite
for PDS/IdH/EDV. The reference implementation is not the standard and is
not the test suite and is not expected to be THE one implementation
everyone should use.
01:09:09        Daniel Buchner:        +1
01:09:10        Orie (Transmute):        +1
01:09:10        Dave Longley:        +1
01:09:10        Joachim Lohkamp (Jolocom):        +1
01:09:11        ET:        +1
01:09:13        Daniel Hardman:        +1
01:09:14        Adrian Gropper:        +1
01:09:16        Rouven Heck:        +1
01:09:17        Christopher Allen:        +1
01:09:18        Joel Hartshorn:        +1
01:09:21        Ken Ebert:        +1
01:09:23        Manu Sporny (Digital Bazaar):        +1
01:09:24        BalazsN:        +1
01:09:26        Ed Goode:        +1
01:09:28        Joe:        +1
01:09:30        jonnycrunch:        +1
01:09:32        Chad Peiper (Verif-y):        +1
01:09:34        Daniel Buchner:        (But there can only be one
Highlander)
01:09:34        katrynadow:        +1 KD +1 Jo +1 Jan
01:09:35        Ganesh Annan:        +1
01:09:38        Troy Ronda:        +1
01:09:45        Dan Burnett:        Problem with ref implementations is
that they do tend to be considered authoritative in practice, but I
don't object
01:09:45        justinwb:        +1
01:09:47        Dan Burnett:        +1


Does anyone object?
Lots of +1s, no objections


Manu: I think we are at a point we can start hosting calls at DIF to
host to talk about this stuff. I think then we can finally get to the
specifics.


Manu: IPR not resolved yet


Manu: further refine what we are talking about. Or IPR?


Manu: we will get to closure on the IPR by the end of the call if we
tackle it now.


Rouven: proposal to talk to this about offline and take it in a smaller
group to deal with IPR with the lawyers in the room - so they can be the
experts.


Manu: You want to focus on IPR?


Rouven: no other way around focus on direction (cause lawyers not in room).


Manu: proposal to focus on talking about IPR; either adopt W3C - or are
we going to tell rouven and w3c to get together in a room and talk about it?


Rouven: We need to discuss JDF lawyers whether they take additional IPR
things moving in to JDF.


Christopher A: not asking for a decision just these two different choices.


Daniel B:  I think we can all agree to W3C’s IPR - I don’t think that is
controversial.


Manu: Proposal is if we just use W3C IPR we can start the calls
immediately. Rouven and lawyers can get together in parallel to decide
if there need to be changes in the future or not. It’s a shortcut. We
may find that there is agreement between DIF, JDF, W3C IPR policies.


Christopher A: I think it has been expressed well. Examples of __ work
expressed in JDF. Start with W3C IPR and explore other options is most
expedient path forward.  And to jonathan’s point there are still some
issues with big companies in both/all organizations that I think are
still challenging but I do believe that things are under the W3C policy
and can go off different places as long as we don’t want to patent it.


Rouven: We take the joint work item.  We would assume that because
people sign up to CCG we are covered in DIF we have a one page IPR member.


Christopher A: you don’t need to be a “W3C Member” to join the CCG (and
be covered by IPR).


Rouven: So we decide to do call next week and then we decide  the DIF
IPR is stronger what are the implications if we decide to switch from
one to the other.


Joe A: There is an unfortunate slight of hand that is happening. There
is a much larger conversation about how DIF W3C work together and would
love to have a clean IPR pathway. There is no W3C policy around things
as we described them.  Community Group collaborators agreement needs to
be looked at.


Manu: Taking everyone down logical choices here. If what Rouven and JDF
lawyers are saying and there is no difference between DIF/JDF IPR and
W3C CCG - there is no problem and we are wasting time if this is true.
Option 1 - use W3C IPR policy and have meetings at DIF. Makes people who
have dealt with W3C and IETF - DIF Should be happy there is no
difference between that and DIF policy. It helps us to have an actual
real call next week and we can start talking about details.


People insist that we use the DIF/JDF IPR policy and people are
concerned which means get the lawyers in the room and have everything
settles and that could take weeks.


Easiest path - heard folks say let’s get this started quickly - easiest
path to use W3C IPR and calls at DIF and get started that way.


If there is disagreement get the lawyers in the room and have them
figure it out.


Jonathan H:  It is about agreeing to the terms and then those terms
being satisfied by W3C and DIF.


Manu -


PROPOSAL 5: The IPR policy would be the "W3C CG IPR policy", not the
"DIF W3C IPR policy". The specification would have the "W3C CG IPR
policy" on it, and anyone that participates in the group MUST be a W3C
CCG member and can, in addition, be a DIF member.


01:22:44        Rouven Heck:        -1
01:22:48        Manu Sporny (Digital Bazaar):        +1
01:22:49        Joachim Lohkamp (Jolocom):        +1
01:22:49        Joe:        +1
01:22:50        Orie (Transmute):        +1
01:22:51        Dave Longley:        +1
01:22:52        Dan Burnett:        +1
01:22:52        Tzviya Siegman:        +1
01:22:55        Kaliya Identity Woman:        +1
01:22:59        Eve Maler (ForgeRock):        +1
01:23:07        Ganesh Annan:        +1
01:23:10        Stuart Freeman:        +1
01:23:11        Adrian Gropper:        +1
01:23:13        Ken Ebert:        +1
01:23:14        bshambaugh:        +1
01:23:18        Christopher Allen:        +1
01:23:18        Dan Burnett:        Daniel, no malice intended - just
the fact that lawyers disagree all the time :)
01:23:21        Tobias Looker:        +1
01:23:22        justin:        +1
01:23:39        Rouven Heck:        We cannot commit to this proposal
today and know the implications
01:23:41        Rouven Heck:        q+
01:23:41        Joe:        q+
01:23:46        BalazsN:        -1


Daniel B: The DIF one is stricter, can we sign both?


Manu: The harm is that there may be subtle disagreements.


Rouven: I think in a nutshell if we agreed to host this in DIF and we
host under a particular IPR agreement - what does it mean. The reason
the DIF IPR policy has been defined the way it is - my understanding is
that it is more strict. If we all agree in January we decide DIF IPR is
stronger what happens? I strongly suggest we not make a decision to
figure out an agreement on this proposal. If someone is a lawyer speak
up now and we can make a decision.


Joe A: Ok so - i’m hearing two different stories from the DIF folks -
one - they are the same two - it is more strict. So all the companies
that have reviewed the W3C to look at CCG and approved their ability to
participate. So if we use DIF IPR then some folks can’t participate
until their lawyers have read the IPR and approved. Even DIF has already
approved W3C IPR.


Daniel B (from chat): q+ what is the track record of moving something
from the CCG under that IRP outside of W3C, to another SDO?
Do we have assurances that we can export that work to IETF, IEEE, etc?


Manu (from chat): yes we do. WebRTC, HTTP, etc.


Rouven: As I said this is why I am thinking the last 20 min to skip I
don’t think we have the right people on the call to have this IPR
figured out. The lawyer that we had worked on - it is slightly more
strict - it is different. We have more then 10 active companies working
on data stores working on data stores at DIF. Yes W3C has 400 members -
is it higher then the number of actual organizations working on code. 20
min with 50 people talking about thing we don’t have expertise.


Manu: Proposal that W3C and DIF need to discuss and this will not move
forward.


Dave Longley: We are going to adopt W3C policy and this is the one the
work would move forward under and we are done.


PROPOSAL 5: The IPR policy will need to be agreed to between DIF and
W3C. Rouven has an action item to move that discussion forward. Meetings
will not begin until this is resolved.


01:29:16        Orie (Transmute):        -1
01:29:29        Rouven Heck:        +1
01:29:33        rhiaro:        Why are DIF unhappy with w3c IPR if it's
'essentially the same'?
01:29:33        Joe:        -1
01:29:34        BalazsN:        +1
01:29:36        Kaliya Identity Woman:        -1
01:29:37        Dave Longley:        -1
01:29:38        Daniel Buchner:        +1
01:29:41        Daniel Buchner:        q+
01:29:45        Adrian Gropper:        +0
01:29:47        Dan Burnett:        +0
01:29:50        Manu Sporny (Digital Bazaar):        +1


Daniel B: As a modification of that. I don’t want to delay anything. I
want to do the work. What if we timeboxed it. You have to give us an
answer by the 6th of January or we fall back to W3C IPR policy.


Rouven: We can agree on anything and the lawyers outside can have an
opinion. I can’t speak on the lawyers’ behalf. That is why I can talk
with them and find out.


Daniel B: That is we figure it out in a month. Or its not. We are or are
not as an organization willing to accept a different IPR policy. If we
do that we at least understand what our answer would be at that time.


Manu: Let me try to synthesize. You have the ED of the DIF saying that
he cannot agree to W3C CG IPR Policy and that he needs to talk to the
lawyers because he is uncertain that we can use W3C CG IPR Policy. So we
have agreed to put this thing at the DIF and it is up to you, Rouven, to
clear this up. Roven has action item to move forward. We have made a
tremendous amount of progress on the call today. Everyone should feel
really good about what we accomplished. I have one other scoping
proposal if we are able to get this done we will be able to get clarity
on what we are working on.


Christopher A:  I look at the number of +1s that we just move forward
with W3C IPR. We could just do that… you can join us later if you like
if you are a DIF only member. DIF members can join W3C CCG for free. We
have done this stuff before and progressed it all the way to an
international standard, we could do the same with this work and start on
it immediately. This is why a long time ago. I thought DIF was going to
do reference implementations and CCG is wanting to do standards and now
that DIF is wanting to do standards, the goal posts are being moved. I'm
expressing frustration.


Manu: I hope you are hearing - there is frustration with this outcome
Rouven. People were expecting DIF to be ready to take on this work and
DIF is not ready. It was said that the W3C and DIF IPR policies were
identical, and now we're hearing that they're not. I hope you are
hearing that loud and clear. People are frustrated.


Joe A: We do not have consensus on this last point.


Manu: Yes, that is true. Although, we are not undoing the other
consensus that we have. The only -1s we got to the use W3C CG IPR Policy
was you Rouven. But since you are the Executive Director, we have no
choice but to go with what you are proposing, which means that we're all
waiting on you and the lawyers to sort it out. We can only kick it over
to the folks at DIF to sort it out.


Daniel B: Can access DIF folks very fast. Who on W3C can we coordinate with?


Manu: Wendy Seltzer and others. We accomplished a lot today. I think the
hardest thing is to get the groups to agree to come together to work on
this at a specific venue - the venue just has to figure out some stuff.


Lets figure out what goes into this specification.
We almost got to a resolution.


PROPOSAL 4: 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 are acknowledged as important related work that might
influence the direction of the collaborative effort.


Ask clarifying questions? Before we pick it up for a straw poll.


Adrian: quick point I if the reference use case does not include Alice
and Bob.


Manu: What does Alice and Bob mean?


Adrian: We are talking about the relationship by agents storage and
relationship to Alice the data subject and the Bob who is the requesting
policy.


Dmitri: Is your concern not addressed by UMA?


Adrian: if we’re starting out with the use case in edv and that use case
is in or out of scope that’s not good enough.


Sam: I had a conversation with Adrian that helped me understand what he
is talking about now. EDVs and Hubs are things stored by the identity
owner. Data provider has data and allows data access; is that mode in or
out of scope?


Manu: I think it is inscope. In this data provider role.


Sam: The data is not necessarily encrypted at rest with the keys of the
user.
 This is a more “traditional” data storage (UMA) stored encrypted of the
keys of the provider not the identity owner.


Manu: Adrian would you like to add another input document that has your
use-case.


Adrian: I would appreciate if Orie and Sam would do that with me.


Straw poll on:


PROPOSAL 4: The Identity Hubs, Encrypted Data Vaults, and Adrian's use
case 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 are acknowledged as important related work
that might influence the direction of the collaborative effort.


01:42:43        Dave Longley:        +1
01:42:45        Orie (Transmute):        +1
01:42:46        Adrian Gropper:        +1
01:42:51        Kaliya Identity Woman:        +1
01:42:56        Joe:        +1
01:42:57        Thomas Hardjono:        +1
01:42:58        BalazsN:        +1
01:42:59        Orie (Transmute):        (I will help with the concern)
01:42:59        Daniel Buchner:        +1
01:42:59        Joachim Lohkamp (Jolocom):        +1
01:43:04        Sam Curren (TelegramSam):        +1
01:43:05        Dan Burnett:        +1
01:43:07        Ken Ebert:        +1
01:43:11        Troy Ronda:        +1
01:43:15        Michael Benaudis - Internet Identity Card:        +1
01:43:16        Chad Peiper (Verif-y):        +1


+1’s it is…


Manu: Thank you very much. Everyone should be very happy with what we
have accomplished.


We will get the minutes out and when the very first call on this work
item can start.

-- 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



Native integration Indy and Fabric

Ultimo
 

Hi everyone, 

Is there maybe an example of Integrating Indy with indy-sdk API and MSP calls from the Fabric?
It would be great to see a working solution, where these two great projects meet from the technical aspect. 

Thanks. 


Indy Semantics WG - Tue, 12/10/2019 #cal-notice

indy@lists.hyperledger.org Calendar <noreply@...>
 

Indy Semantics WG

When:
Tuesday, 10 December 2019
11:00am to 12:15pm
(GMT-07:00) America/Denver

Where:
https://zoom.us/j/2157245727

Organizer:
ken@...

Description:
These calls provide an opportunity for Hyperledger Indy community members to discuss issues pertaining to the Semantics layer of the stack. Anyone is welcome to join the call.

Perpetual Meeting Notes :
https://docs.google.com/document/d/1ayXu4JLznvi1-qM0mRRN24EPuAWpAeV4f1f6DqSKG5c/edit?usp=sharing

Join from PC, Mac, Linux, iOS or Android :
https://zoom.us/j/2157245727

Or iPhone one-tap :
US: +16465588665,,2157245727# or +14086380986,,2157245727#

Or by Telephone :
https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1


Upcoming Event: Indy Semantics WG - Tue, 12/10/2019 11:00am-12:15pm #cal-reminder

indy@lists.hyperledger.org Calendar <indy@...>
 

Reminder: Indy Semantics WG

When: Tuesday, 10 December 2019, 11:00am to 12:15pm, (GMT-07:00) America/Denver

Where:https://zoom.us/j/2157245727

View Event

Organizer: Ken Ebert ken@...

Description: These calls provide an opportunity for Hyperledger Indy community members to discuss issues pertaining to the Semantics layer of the stack. Anyone is welcome to join the call.

Perpetual Meeting Notes :
https://docs.google.com/document/d/1ayXu4JLznvi1-qM0mRRN24EPuAWpAeV4f1f6DqSKG5c/edit?usp=sharing

Join from PC, Mac, Linux, iOS or Android :
https://zoom.us/j/2157245727

Or iPhone one-tap :
US: +16465588665,,2157245727# or +14086380986,,2157245727#

Or by Telephone :
https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1


Indy Contributors Call - Mon, 12/09/2019 #cal-notice

indy@lists.hyperledger.org Calendar <noreply@...>
 

Indy Contributors Call

When:
Monday, 9 December 2019
4:00pm to 5:00pm
(GMT-07:00) America/Denver

Where:
https://zoom.us/j/615818107

Organizer:
richard.esplin@...

Description:
The Indy Contributors call provides an opportunity to get an update on Indy work, help others understand your contribution, resolve complex challenges, discuss roadmap commitments, and identity cross-team dependencies.

The call rotates between two timezones to give as many contributors as possible the opportunity to participate.

Feel free to add a topic to the meeting agenda. The meeting agenda will be posted here:

https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/615818107
International numbers available: https://zoom.us/u/akZ4IVIpQ


Upcoming Event: Indy Contributors Call - Mon, 12/09/2019 4:00pm-5:00pm #cal-reminder

indy@lists.hyperledger.org Calendar <indy@...>
 

Reminder: Indy Contributors Call

When: Monday, 9 December 2019, 4:00pm to 5:00pm, (GMT-07:00) America/Denver

Where:https://zoom.us/j/615818107

View Event

Organizer: Richard Esplin richard.esplin@...

Description: The Indy Contributors call provides an opportunity to get an update on Indy work, help others understand your contribution, resolve complex challenges, discuss roadmap commitments, and identity cross-team dependencies.

The call rotates between two timezones to give as many contributors as possible the opportunity to participate.

Feel free to add a topic to the meeting agenda. The meeting agenda will be posted here:

https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/615818107
International numbers available: https://zoom.us/u/akZ4IVIpQ


Cancelled Event: Indy Semantics WG - Tuesday, 24 December 2019 #cal-cancelled

indy@lists.hyperledger.org Calendar <indy@...>
 

Cancelled: Indy Semantics WG

This event has been cancelled.

When:
Tuesday, 24 December 2019
11:00am to 12:15pm
(UTC-07:00) America/Denver

Where:
https://zoom.us/j/2157245727

Organizer: Ken Ebert ken@...

Description:
These calls provide an opportunity for Hyperledger Indy community members to discuss issues pertaining to the Semantics layer of the stack. Anyone is welcome to join the call.

Perpetual Meeting Notes :
https://docs.google.com/document/d/1ayXu4JLznvi1-qM0mRRN24EPuAWpAeV4f1f6DqSKG5c/edit?usp=sharing

Join from PC, Mac, Linux, iOS or Android :
https://zoom.us/j/2157245727

Or iPhone one-tap :
US: +16465588665,,2157245727# or +14086380986,,2157245727#

Or by Telephone :
https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1


Cancelled Event: Indy Contributors Call - Monday, 6 January 2020 #cal-cancelled

indy@lists.hyperledger.org Calendar <indy@...>
 

Cancelled: Indy Contributors Call

This event has been cancelled.

When:
Monday, 6 January 2020
4:00pm to 5:00pm
(UTC-07:00) America/Denver

Where:
https://zoom.us/j/615818107

Organizer: Richard Esplin richard.esplin@...

Description:
The Indy Contributors call provides an opportunity to get an update on Indy work, help others understand your contribution, resolve complex challenges, discuss roadmap commitments, and identity cross-team dependencies.

The call rotates between two timezones to give as many contributors as possible the opportunity to participate.

Feel free to add a topic to the meeting agenda. The meeting agenda will be posted here:

https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/615818107
International numbers available: https://zoom.us/u/akZ4IVIpQ


Cancelled Event: Indy Contributors Call - Monday, 23 December 2019 #cal-cancelled

indy@lists.hyperledger.org Calendar <indy@...>
 

Cancelled: Indy Contributors Call

This event has been cancelled.

When:
Monday, 23 December 2019
4:00pm to 5:00pm
(UTC-07:00) America/Denver

Where:
https://zoom.us/j/615818107

Organizer: Richard Esplin richard.esplin@...

Description:
The Indy Contributors call provides an opportunity to get an update on Indy work, help others understand your contribution, resolve complex challenges, discuss roadmap commitments, and identity cross-team dependencies.

The call rotates between two timezones to give as many contributors as possible the opportunity to participate.

Feel free to add a topic to the meeting agenda. The meeting agenda will be posted here:

https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/615818107
International numbers available: https://zoom.us/u/akZ4IVIpQ


Cancelled Event: Indy Contributors Call - Monday, 30 December 2019 #cal-cancelled

indy@lists.hyperledger.org Calendar <indy@...>
 

Cancelled: Indy Contributors Call

This event has been cancelled.

When:
Monday, 30 December 2019
9:00am to 10:00am
(UTC-07:00) America/Denver

Where:
https://zoom.us/j/615818107

Organizer: Richard Esplin richard.esplin@...

Description:
The Indy Contributors call provides an opportunity to get an update on Indy work, help others understand your contribution, resolve complex challenges, discuss roadmap commitments, and identity cross-team dependencies.

The call rotates between two timezones to give as many contributors as possible the opportunity to participate.

Feel free to add a topic to the meeting agenda. The meeting agenda will be posted here:

https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/615818107
International numbers available: https://zoom.us/u/akZ4IVIpQ


Updated Event: Hyperledger Indy SDK coordination #cal-invite

indy@lists.hyperledger.org Calendar <indy@...>
 

Hyperledger Indy SDK coordination

When:
Wednesday, 13 March 2019
9:30am to 10:30am
(UTC-07:00) America/Phoenix
Repeats: Every 2 weeks on Wednesday, through Tuesday, 3 December 2019

Where:
https://zoom.us/j/6385450258

Organizer: Hyperledger Community Meetings linuxfoundation.org_nf9u64g9k9rvd9f8vp4vur23b0@...

Description:
Reserving a time every two weeks to coordinate efforts on the Indy SDK.
This does not replace our asynchronous collaboration, but should help
us keep everyone up-to-date and moving forward.

Agenda:

https://docs.google.com/document/d/12thubl-h8L09drqt3Bjb3EOqr4-32UJtUAqALc928I8/edit

Discussion items:
* Upcoming releases
* Current PRs
* Work that will generate future PRs
* Architecture changes that will impact downstream teams
* Project standards, best practices, design, etc.

-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
Please do not edit this section of the description.

View your event at https://www.google.com/calendar/event?action=VIEW&eid=NXVscGxwYmhhN3VzbDh1bnEwbm4wcTZlcW4gaW5keUBsaXN0cy5oeXBlcmxlZGdlci5vcmc&tok=NzIjbGludXhmb3VuZGF0aW9uLm9yZ19uZjl1NjRnOWs5cnZkOWY4dnA0dnVyMjNiMEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tZTQwZjc4ODZhZDUzMDAzYmM3NDFlNGU2MDljZDQ4MjkzMDhlYmUwOA&ctz=America%2FLos_Angeles&hl=en&es=1.
-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-


Re: concerns about personal data hubs, identity hubs, EDV

Adrian Gropper
 

I think the MVP / Separation of Concerns model is consistent with this thread. 
- Alice can self-host a hub as well as an authorization server. 
- Any hub, no matter who hosts it can authenticate Alice with her DID, true to SSI principles. 
- Any RqP / Bob or Carol can bring a capability to any hub. That capability might be in the form of a Verifiable Presentation. 
- How Alice’s DID or Bob’s VP are managed are transported to the hub is a SHOULD, not a MUST.


Re: Need support for Joining a new node

Antonio Antonino
 

Does this help? https://github.com/Diiaablo95/Indy_Public_Pool

\Antonio

On 21 Nov 2019, at 08:52, shashanksaxena18@... wrote:



I have a indy network up and running on one server, I wish to have a organisation running on a different server.

Now to be able to interact with the indy private network, server 2 should be connected to server 1.

Can anyone please help me with the process.


Need support for Joining a new node

shashanksaxena18@...
 

I have a indy network up and running on one server, I wish to have a organisation running on a different server.

Now to be able to interact with the indy private network, server 2 should be connected to server 1.

Can anyone please help me with the process.


Re: concerns about personal data hubs, identity hubs, EDV

Sam Curren
 

All the wise stuff has already been said, but I wanted to underline the importance of " secure communication with agents/hubs in a way that's rooted in DIDs (e.g. using DIDComm, but could also be DID-TLS or something else)." -Markus

I think it is fundamentally important that the communication layer for anything storage/hubs related and agents be based on that same foundation.

On Mon, Nov 18, 2019 at 12:17 PM Markus Sabadello <markus@...> wrote:

I agree that both aspects of SSI are important, and that reliance on classic CAs breaks SSI principles.

But regarding your first point, I don't think there's a difference between the agent concept and hub concept in terms of how the respective communities feel about disintermediation.
I believe the narratives are that hubs and agents can either be self-hosted, or hosted by third parties, with the same pros and cons in each case.
At least that's how it should be, maybe I missed something there.

Anyway, also +1 to secure communication with agents/hubs in a way that's rooted in DIDs (e.g. using DIDComm, but could also be DID-TLS or something else).

Markus

On 11/18/19 4:46 PM, Daniel Hardman wrote:
This email is a comment about the architecture that's beginning to coalesce around the data hub concept. It is not me trying to derail the effort--I think it's good and important--but me trying to raise a cautionary flag and trigger some thoughtful dialog.

In our understandable enthusiasm to solve a nagging problem for everyone, I am worried that we might end up losing two aspects of SSI that matter a lot:

1. disintermediation
2. identity through DIDs

Regarding disintermediation, a core value that I see in SSI is the notion that I--not some third party with a paternalistic posture that I have to trust to get anything done--am the authority for myself. If people want my data, they have to get it from me. If they want to see my credentials, they have to ask me for them, not somebody else. If they want my consent, they have to ask me for it, not somebody else. If I want to audit what's happening, I audit my own records, not somebody else's.

To the extent that the posture of a hub is closer to a brokering service for my data, configured by me but operated by a third party that requires me to trust it, I think this aspect of self-sovereignty is seriously weakened. The notion that I am putting the data into the hub in encrypted form does not, in and of itself, alleviate this concern for me; however, how the encryption is controlled might make me more or less concerned. Portability of data out of the hub into a different hub or something that's not a hub at all would make a difference, too.

Now, I get that not everybody in our decentralized identity circles is explicitly pursuing SSI. Some of us will be perfectly content to building something that's decentralized but not self-sovereign. And that is fine, IMO. But I would like the architecture of hubs not to preclude self-sovereign versions of hubs. This means that I would like it to be possible for Alice to put a hub interface behind her own identity (and her own DID) rather than the identity of a third party hub-serving intermediary. If we can design hub interfaces such that this is a first-class mode of operation, I will feel cheerful about this issue.

Regarding identity through DIDs: it feels ironic to me that we have spent vast amounts of energy talking about how to prove control of an identifier associated with a particular identity subject, through the DID mechanism--and we then throw our wood/energy behind an approach that exposes all personal data through intermediaries, where those intermediaries interact in both directions through a different security mechanism (TLS with certs and logins/API keys). If hubs are as important to identity as we think, and they take off, and if they are exclusively TLS-centric, we've basically cut the legs out from under DIDs.

I get that RESTful, TLS-central interaces are ubiquitous and easy, so it's worth exposing them. I am not opposed to a hub mechanism that includes that sort of interface; what I am worried about is a hub mechanism that doesn't also include a mechanism secured by DIDs and their keys, such that builders of hubs don't get limited just to orgs with certs and trust derived from CAs (the very trust architecture we are hoping to upgrade). Therefore, I am looking for any spec that gets written to include the ability to interface with hubs over DIDComm. This means that in the non-TLS mode, I ought to be able to authenticate the hub itself, plus any party that interacts with a hub, using the keys in my DID doc, NOT using certs and logins and API keys.



Re: concerns about personal data hubs, identity hubs, EDV

Markus Sabadello
 

I agree that both aspects of SSI are important, and that reliance on classic CAs breaks SSI principles.

But regarding your first point, I don't think there's a difference between the agent concept and hub concept in terms of how the respective communities feel about disintermediation.
I believe the narratives are that hubs and agents can either be self-hosted, or hosted by third parties, with the same pros and cons in each case.
At least that's how it should be, maybe I missed something there.

Anyway, also +1 to secure communication with agents/hubs in a way that's rooted in DIDs (e.g. using DIDComm, but could also be DID-TLS or something else).

Markus

On 11/18/19 4:46 PM, Daniel Hardman wrote:
This email is a comment about the architecture that's beginning to coalesce around the data hub concept. It is not me trying to derail the effort--I think it's good and important--but me trying to raise a cautionary flag and trigger some thoughtful dialog.

In our understandable enthusiasm to solve a nagging problem for everyone, I am worried that we might end up losing two aspects of SSI that matter a lot:

1. disintermediation
2. identity through DIDs

Regarding disintermediation, a core value that I see in SSI is the notion that I--not some third party with a paternalistic posture that I have to trust to get anything done--am the authority for myself. If people want my data, they have to get it from me. If they want to see my credentials, they have to ask me for them, not somebody else. If they want my consent, they have to ask me for it, not somebody else. If I want to audit what's happening, I audit my own records, not somebody else's.

To the extent that the posture of a hub is closer to a brokering service for my data, configured by me but operated by a third party that requires me to trust it, I think this aspect of self-sovereignty is seriously weakened. The notion that I am putting the data into the hub in encrypted form does not, in and of itself, alleviate this concern for me; however, how the encryption is controlled might make me more or less concerned. Portability of data out of the hub into a different hub or something that's not a hub at all would make a difference, too.

Now, I get that not everybody in our decentralized identity circles is explicitly pursuing SSI. Some of us will be perfectly content to building something that's decentralized but not self-sovereign. And that is fine, IMO. But I would like the architecture of hubs not to preclude self-sovereign versions of hubs. This means that I would like it to be possible for Alice to put a hub interface behind her own identity (and her own DID) rather than the identity of a third party hub-serving intermediary. If we can design hub interfaces such that this is a first-class mode of operation, I will feel cheerful about this issue.

Regarding identity through DIDs: it feels ironic to me that we have spent vast amounts of energy talking about how to prove control of an identifier associated with a particular identity subject, through the DID mechanism--and we then throw our wood/energy behind an approach that exposes all personal data through intermediaries, where those intermediaries interact in both directions through a different security mechanism (TLS with certs and logins/API keys). If hubs are as important to identity as we think, and they take off, and if they are exclusively TLS-centric, we've basically cut the legs out from under DIDs.

I get that RESTful, TLS-central interaces are ubiquitous and easy, so it's worth exposing them. I am not opposed to a hub mechanism that includes that sort of interface; what I am worried about is a hub mechanism that doesn't also include a mechanism secured by DIDs and their keys, such that builders of hubs don't get limited just to orgs with certs and trust derived from CAs (the very trust architecture we are hoping to upgrade). Therefore, I am looking for any spec that gets written to include the ability to interface with hubs over DIDComm. This means that in the non-TLS mode, I ought to be able to authenticate the hub itself, plus any party that interacts with a hub, using the keys in my DID doc, NOT using certs and logins and API keys.



Re: concerns about personal data hubs, identity hubs, EDV

Samuel Smith
 

Clarification: The former (ie end-to-end to originator not intermediary) should be the default.

On 18 Nov 2019, at 09:27 , ProSapien Sam Smith <sam@...> wrote:

I want to echo Daniels concerns about SSI at least the sovereignty part.  There is a subtle but very important distinction between a proxy service that acts on the behalf of  DID controller using end-to-end authentication back to the DID controller and an intermediary service that is authenticated with its own DID to serve up a third parties data.  This should be the default.

In some cases, however, (high volume) it may make sense to have a intermediary sign things (versus end-to-end back to originator). But that signing authority should be under the control of the originator controller not the intermediary.
KERI includes the concept of hierarchical delegated keys/identifiers. This allows a controller to delegate a set of signing keys/identifiers to a proxy but those keys are controlled by the delegator and may be revoked/rotated away from the intermediary delegate at the discretion of the delegator. This allows true portability of the underlying identifiers. The delegator may merely change delegation via a rotation event to port their signing delegation to a new intermediary. A compliant intermediary would support an API for a new delegate to download the data from the old delegate. The rotation event indicates the control authority of the new delegate to extract the data from the old delegate.

This approach when coupled with derived DIDs  (see the DAD paper RWOT7) preserves the essential characteristics of self-sovereignty in more hierarchical or complex arrangements.


On 18 Nov 2019, at 08:46 , Daniel Hardman <daniel.hardman@...> wrote:

This email is a comment about the architecture that's beginning to coalesce around the data hub concept. It is not me trying to derail the effort--I think it's good and important--but me trying to raise a cautionary flag and trigger some thoughtful dialog.

In our understandable enthusiasm to solve a nagging problem for everyone, I am worried that we might end up losing two aspects of SSI that matter a lot:

1. disintermediation
2. identity through DIDs

Regarding disintermediation, a core value that I see in SSI is the notion that I--not some third party with a paternalistic posture that I have to trust to get anything done--am the authority for myself. If people want my data, they have to get it from me. If they want to see my credentials, they have to ask me for them, not somebody else. If they want my consent, they have to ask me for it, not somebody else. If I want to audit what's happening, I audit my own records, not somebody else's.

To the extent that the posture of a hub is closer to a brokering service for my data, configured by me but operated by a third party that requires me to trust it, I think this aspect of self-sovereignty is seriously weakened. The notion that I am putting the data into the hub in encrypted form does not, in and of itself, alleviate this concern for me; however, how the encryption is controlled might make me more or less concerned. Portability of data out of the hub into a different hub or something that's not a hub at all would make a difference, too.

Now, I get that not everybody in our decentralized identity circles is explicitly pursuing SSI. Some of us will be perfectly content to building something that's decentralized but not self-sovereign. And that is fine, IMO. But I would like the architecture of hubs not to preclude self-sovereign versions of hubs. This means that I would like it to be possible for Alice to put a hub interface behind her own identity (and her own DID) rather than the identity of a third party hub-serving intermediary. If we can design hub interfaces such that this is a first-class mode of operation, I will feel cheerful about this issue.

Regarding identity through DIDs: it feels ironic to me that we have spent vast amounts of energy talking about how to prove control of an identifier associated with a particular identity subject, through the DID mechanism--and we then throw our wood/energy behind an approach that exposes all personal data through intermediaries, where those intermediaries interact in both directions through a different security mechanism (TLS with certs and logins/API keys). If hubs are as important to identity as we think, and they take off, and if they are exclusively TLS-centric, we've basically cut the legs out from under DIDs.

I get that RESTful, TLS-central interaces are ubiquitous and easy, so it's worth exposing them. I am not opposed to a hub mechanism that includes that sort of interface; what I am worried about is a hub mechanism that doesn't also include a mechanism secured by DIDs and their keys, such that builders of hubs don't get limited just to orgs with certs and trust derived from CAs (the very trust architecture we are hoping to upgrade). Therefore, I am looking for any spec that gets written to include the ability to interface with hubs over DIDComm. This means that in the non-TLS mode, I ought to be able to authenticate the hub itself, plus any party that interacts with a hub, using the keys in my DID doc, NOT using certs and logins and API keys.



Samuel M. Smith Ph.D.   Founder
ProSapien LLC
242 East 600 North, Lindon Utah 84042-1662 USA
Office 1.801.768-2769
Mobile 1.801.592.8230
Skype: samuelmsmith

NOTICE: This electronic mail message, together with any attachments contains information
that may be copyrighted, confidential, proprietary, and/or legally privileged of and/or by 
ProSapien LLC. This  electronic mail message is intended solely for the use of
the individual or entity originally named as the intended recipient. If you are not the intended
recipient, and have received this message in error, please return immediately this message












Samuel M. Smith Ph.D.   Founder
ProSapien LLC
242 East 600 North, Lindon Utah 84042-1662 USA
Office 1.801.768-2769
Mobile 1.801.592.8230
Skype: samuelmsmith

NOTICE: This electronic mail message, together with any attachments contains information
that may be copyrighted, confidential, proprietary, and/or legally privileged of and/or by 
ProSapien LLC. This  electronic mail message is intended solely for the use of
the individual or entity originally named as the intended recipient. If you are not the intended
recipient, and have received this message in error, please return immediately this message











Re: concerns about personal data hubs, identity hubs, EDV

Samuel Smith
 

I want to echo Daniels concerns about SSI at least the sovereignty part.  There is a subtle but very important distinction between a proxy service that acts on the behalf of  DID controller using end-to-end authentication back to the DID controller and an intermediary service that is authenticated with its own DID to serve up a third parties data.  This should be the default.

In some cases, however, (high volume) it may make sense to have a intermediary sign things (versus end-to-end back to originator). But that signing authority should be under the control of the originator controller not the intermediary.
KERI includes the concept of hierarchical delegated keys/identifiers. This allows a controller to delegate a set of signing keys/identifiers to a proxy but those keys are controlled by the delegator and may be revoked/rotated away from the intermediary delegate at the discretion of the delegator. This allows true portability of the underlying identifiers. The delegator may merely change delegation via a rotation event to port their signing delegation to a new intermediary. A compliant intermediary would support an API for a new delegate to download the data from the old delegate. The rotation event indicates the control authority of the new delegate to extract the data from the old delegate.

This approach when coupled with derived DIDs  (see the DAD paper RWOT7) preserves the essential characteristics of self-sovereignty in more hierarchical or complex arrangements.


On 18 Nov 2019, at 08:46 , Daniel Hardman <daniel.hardman@...> wrote:

This email is a comment about the architecture that's beginning to coalesce around the data hub concept. It is not me trying to derail the effort--I think it's good and important--but me trying to raise a cautionary flag and trigger some thoughtful dialog.

In our understandable enthusiasm to solve a nagging problem for everyone, I am worried that we might end up losing two aspects of SSI that matter a lot:

1. disintermediation
2. identity through DIDs

Regarding disintermediation, a core value that I see in SSI is the notion that I--not some third party with a paternalistic posture that I have to trust to get anything done--am the authority for myself. If people want my data, they have to get it from me. If they want to see my credentials, they have to ask me for them, not somebody else. If they want my consent, they have to ask me for it, not somebody else. If I want to audit what's happening, I audit my own records, not somebody else's.

To the extent that the posture of a hub is closer to a brokering service for my data, configured by me but operated by a third party that requires me to trust it, I think this aspect of self-sovereignty is seriously weakened. The notion that I am putting the data into the hub in encrypted form does not, in and of itself, alleviate this concern for me; however, how the encryption is controlled might make me more or less concerned. Portability of data out of the hub into a different hub or something that's not a hub at all would make a difference, too.

Now, I get that not everybody in our decentralized identity circles is explicitly pursuing SSI. Some of us will be perfectly content to building something that's decentralized but not self-sovereign. And that is fine, IMO. But I would like the architecture of hubs not to preclude self-sovereign versions of hubs. This means that I would like it to be possible for Alice to put a hub interface behind her own identity (and her own DID) rather than the identity of a third party hub-serving intermediary. If we can design hub interfaces such that this is a first-class mode of operation, I will feel cheerful about this issue.

Regarding identity through DIDs: it feels ironic to me that we have spent vast amounts of energy talking about how to prove control of an identifier associated with a particular identity subject, through the DID mechanism--and we then throw our wood/energy behind an approach that exposes all personal data through intermediaries, where those intermediaries interact in both directions through a different security mechanism (TLS with certs and logins/API keys). If hubs are as important to identity as we think, and they take off, and if they are exclusively TLS-centric, we've basically cut the legs out from under DIDs.

I get that RESTful, TLS-central interaces are ubiquitous and easy, so it's worth exposing them. I am not opposed to a hub mechanism that includes that sort of interface; what I am worried about is a hub mechanism that doesn't also include a mechanism secured by DIDs and their keys, such that builders of hubs don't get limited just to orgs with certs and trust derived from CAs (the very trust architecture we are hoping to upgrade). Therefore, I am looking for any spec that gets written to include the ability to interface with hubs over DIDComm. This means that in the non-TLS mode, I ought to be able to authenticate the hub itself, plus any party that interacts with a hub, using the keys in my DID doc, NOT using certs and logins and API keys.



Samuel M. Smith Ph.D.   Founder
ProSapien LLC
242 East 600 North, Lindon Utah 84042-1662 USA
Office 1.801.768-2769
Mobile 1.801.592.8230
Skype: samuelmsmith

NOTICE: This electronic mail message, together with any attachments contains information
that may be copyrighted, confidential, proprietary, and/or legally privileged of and/or by 
ProSapien LLC. This  electronic mail message is intended solely for the use of
the individual or entity originally named as the intended recipient. If you are not the intended
recipient, and have received this message in error, please return immediately this message