Date   

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











concerns about personal data hubs, identity hubs, EDV

Daniel Hardman
 

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: Scope of PDS/IdH/EDV Discussion (Re: Invitation to Personal Data Hubs, Identity Hubs, EDV Roadmap Discussion)

Daniel Hardman
 

My point was that the contrast is misleading.

A more insightful contrast would be DIDComm vs. RESTful web services secured by certificates + user login. Both run over HTTP, and both are a "whole extra layer over simple HTTP."

On Sun, Nov 17, 2019 at 6:43 PM Lucas Tétreault <lucas@...> wrote:
The discussions I've heard indicate one of the goals of DIDComm is to be transport agnostic. Either way, it's still a whole extra layer over simple HTTP....


From: Daniel Hardman <daniel.hardman@...>
Sent: Sunday, November 17, 2019, 7:10 p.m.
To: Manu Sporny
Cc: Michael Herman (Parallelspace); Daniel Buchner; Sam Curren; aries@...; indy@...; Rouven Heck; W3C Credentials CG; Tobias Looker; Orie Steele; Dmitri Zagidulin
Subject: Re: Scope of PDS/IdH/EDV Discussion (Re: Invitation to Personal Data Hubs, Identity Hubs, EDV Roadmap Discussion)

Other protocol work, like communication over DIDComm,
  Bluetooth, CoAP, etc. should continue to be incubated at DIF and
  Aries.

HTTP and DIDComm are not alternatives to one another. DIDComm runs over HTTP.


Re: Scope of PDS/IdH/EDV Discussion (Re: Invitation to Personal Data Hubs, Identity Hubs, EDV Roadmap Discussion)

Daniel Hardman
 

Other protocol work, like communication over DIDComm,
  Bluetooth, CoAP, etc. should continue to be incubated at DIF and
  Aries.

HTTP and DIDComm are not alternatives to one another. DIDComm runs over HTTP.


Re: Invitation to Personal Data Hubs, Identity Hubs, EDV Roadmap Discussion

Daniel Hardman
 

After collaboration by a number of people in each community, there is a
technical/architectural approach that seems to be gaining momentum. ..
The conversation absolutely should not attempt to suggest new
technical/architectural approaches

That's fine.

However, I feel a need to express some concerns. Would you recommend that I do that by email?


Re: Invitation to Personal Data Hubs, Identity Hubs, EDV Roadmap Discussion

Stephen Curran
 

I don't really understand the points raised in the first reference - the slide deck. I know that Adrian presented this slide deck at this week's CCG Meeting. Is there a recording of that presentation available so we can better understand what we should gain from the presentation?

Thanks

On Fri, Nov 15, 2019 at 2:34 PM Manu Sporny <msporny@...> wrote:
Hi all,

There have been a set of discussions happening over the past several
months across the DIF, Aries, IIW, RWoT, and W3C CCG communities related
to personal data storage (aka Identity Hubs, Encrypted Data Vaults,
Secure Data Hubs, Solid Pods, etc.).

I've been speaking with a number of people in each community and it
seems like there is momentum to avoid duplication of effort. Key
individuals in the various communities have agreed to participate in a
call on neutral territory to work on the following items:

1. Discuss a plan on how we work together.
2. Discuss where the work could happen.
3. Discuss the Intellectual Property regime for the work.

To be clear, this call will not involve any discussion concerning
Intellectual Property or technical details. The purpose of the call is
to come to consensus out how all three communities will work together on
a common foundational layer related to personal data storage.

Please come to the call if you have an opinion about how you would like
this personal data storage work to progress across these various
communities. Please share this message with anyone that you feel should
be on this upcoming call.

Reading the following documents will help prepare yourself for the call:

https://docs.google.com/presentation/d/1OBgDCUNPsd6LKApO1nrQ3RuriCoZgls5_UsUN0rZOvk/edit?usp=sharing

https://github.com/decentralized-identity/identity-hub/blob/master/explainer.md

https://github.com/WebOfTrustInfo/rwot9-prague/raw/master/final-documents/encrypted-data-vaults.pdf

Dial in information for the call can be found below:

Time : 12pm ET - Friday, November 22nd, 2019 (next Friday)
Where: https://zoom.us/j/358615366

One tap mobile
+16468769923,,358615366# US (New York)
+14086380968,,358615366# US (San Jose)
Meeting ID: 358 615 366

Dial by your location
        +1 646 876 9923 US (New York)
        +1 408 638 0968 US (San Jose)
        +1 669 900 6833 US (San Jose)
Meeting ID: 358 615 366
Find your local number: https://zoom.us/u/acqUJFUODw

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



--

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)

Schedule a Meeting: https://calendly.com/swcurran


invitation to meeting about personal data hubs

Daniel Hardman
 

Posting this at Manu Sporny's request:

Hi all,

There have been a set of discussions happening over the past several
months across the DIF, Aries, IIW, RWoT, and W3C CCG communities related
to personal data storage (aka Identity Hubs, Encrypted Data Vaults,
Secure Data Hubs, Solid Pods, etc.).

I've been speaking with a number of people in each community and it
seems like there is momentum to avoid duplication of effort. Key
individuals in the various communities have agreed to participate in a
call on neutral territory to work on the following items:

1. Discuss a plan on how we work together.
2. Discuss where the work could happen.
3. Discuss the Intellectual Property regime for the work.

To be clear, this call will not involve any discussion concerning
Intellectual Property or technical details. The purpose of the call is
to come to consensus out how all three communities will work together on
a common foundational layer related to personal data storage.

Please come to the call if you have an opinion about how you would like
this personal data storage work to progress across these various
communities. Please share this message with anyone that you feel should
be on this upcoming call.

Reading the following documents will help prepare yourself for the call:

https://docs.google.com/presentation/d/1OBgDCUNPsd6LKApO1nrQ3RuriCoZgls5_UsUN0rZOvk/edit?usp=sharing

https://github.com/decentralized-identity/identity-hub/blob/master/explainer.md

https://github.com/WebOfTrustInfo/rwot9-prague/raw/master/final-documents/encrypted-data-vaults.pdf

Dial in information for the call can be found below:

Time : 12pm ET - Friday, November 22nd, 2019 (next Friday)
Where: https://zoom.us/j/358615366

One tap mobile
+16468769923,,358615366# US (New York)
+14086380968,,358615366# US (San Jose)
Meeting ID: 358 615 366

Dial by your location
        +1 646 876 9923 US (New York)
        +1 408 638 0968 US (San Jose)
        +1 669 900 6833 US (San Jose)
Meeting ID: 358 615 366
Find your local number: https://zoom.us/u/acqUJFUODw

-- manu


Re: Invitation to Personal Data Hubs, Identity Hubs, EDV Roadmap Discussion

Daniel Hardman
 

Thanks.

I have reposted this on the Rocket.Chat instance used by the Aries community.

On Fri, Nov 15, 2019 at 3:32 PM Manu Sporny <msporny@...> wrote:
Hi all,

There have been a set of discussions happening over the past several
months across the DIF, Aries, IIW, RWoT, and W3C CCG communities related
to personal data storage (aka Identity Hubs, Encrypted Data Vaults,
Secure Data Hubs, Solid Pods, etc.).

I've been speaking with a number of people in each community and it
seems like there is momentum to avoid duplication of effort. Key
individuals in the various communities have agreed to participate in a
call on neutral territory to work on the following items:

1. Discuss a plan on how we work together.
2. Discuss where the work could happen.
3. Discuss the Intellectual Property regime for the work.

To be clear, this call will not involve any discussion concerning
Intellectual Property or technical details. The purpose of the call is
to come to consensus out how all three communities will work together on
a common foundational layer related to personal data storage.

Please come to the call if you have an opinion about how you would like
this personal data storage work to progress across these various
communities. Please share this message with anyone that you feel should
be on this upcoming call.

Reading the following documents will help prepare yourself for the call:

https://docs.google.com/presentation/d/1OBgDCUNPsd6LKApO1nrQ3RuriCoZgls5_UsUN0rZOvk/edit?usp=sharing

https://github.com/decentralized-identity/identity-hub/blob/master/explainer.md

https://github.com/WebOfTrustInfo/rwot9-prague/raw/master/final-documents/encrypted-data-vaults.pdf

Dial in information for the call can be found below:

Time : 12pm ET - Friday, November 22nd, 2019 (next Friday)
Where: https://zoom.us/j/358615366

One tap mobile
+16468769923,,358615366# US (New York)
+14086380968,,358615366# US (San Jose)
Meeting ID: 358 615 366

Dial by your location
        +1 646 876 9923 US (New York)
        +1 408 638 0968 US (San Jose)
        +1 669 900 6833 US (San Jose)
Meeting ID: 358 615 366
Find your local number: https://zoom.us/u/acqUJFUODw

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


Re: Trust of first use question - invitations between DIDs and MITM

Daniel Hardman
 

Manas, your scenario could theoretically happen, but it assumes a carelessness by B that feels unrealistic to me. Essentially, B is deciding to share private info with an unknown stranger. If B decides to do that, then of course bad things can happen--but the bad things are the result of B's bad decision, not the result of a protocol that lacks key protections.

ALL proving with verifiable credentials, whether it uses Indy or not, and whether it's related to connecting/DID exchange or not, should ALWAYS begin with the question, "Do I really want to prove these facts to the other party?" I would not prove my date of birth and SSN to a complete stranger, remotely, using today's physical credentials--so why would I prove it using tomorrow's verifiable credential ecosystem?

When the verifier is an institution (which is the most common variant of use cases that most people in the VC space are implementing today), then the verifier has less privacy concerns than the private individual, so the verifier should prove first--not in parallel. Example: verifier is Thrift Bank, and asks Alice to prove her SSN and date of birth. Before Alice decides whether to honor the request, she says, "Prove who you are" -- and Thrift Bank does so. Once Alice knows who she's talking to, she then decides whether to reveal the PII that's being requested. Not before.

This gets harder when both parties are private individuals, because then you can have a chicken-and-egg problem. But in those cases, I believe that one or both of the following conditions will usually be true:

A. There's some supporting context that makes the proving more reasonable. For example, the two parties just met face-to-face at a conference, are standing next to one another, and have already reached a certain level of trust. Or one individual is a seller on Amazon and the other is a potential buyer; the the seller can reasonably prove seller reputation to start the sharing.

B. Trust can be ratcheted in stages. Instead of going straight for sensitive PII like a social security number, you could begin by disclosing low-trust things (prove that you're a ticket holder for this plane flight; prove your initials and the zip code you live in), and you only get to the high-risk proofs once you've laid an appropriate foundation. This ratcheting is particularly easy when you have predicates and ZKPs, but it can also be done with other credential types.