Duplicate of PR 122 Will fix #97

[philarcher]

This is a duplicate of PR 122 that starts from the updated document, thus avoiding having to re-do recent PRs that removed duplicate sections. A couple of utterly trivial edits were made to the text.

---

Preview | Diff

[creatornader]

Hey @philarcher, just tried to push my changes to your branch but got an error because I don't have access rights to push directly to the repo. How best to proceed?

[philarcher]

I don't know how to change that, sorry. What a palaver... OK, please just send me the altered text and I'll add it to this PR. There's bound to be a better way but I'm not GH-savvy enough to know what that is.

[creatornader]

Was able to open a PR against your branch, so if this is merged then it's good to go from my end :) https://github.com/w3c/did-use-cases/pull/129

[philarcher]

Done!

Thank you. @jandrieu didn't get to speak today (it happens). Joe, if you're happy, please go ahead and merge this one and close the others (without merging!)

[TelegramSam]

In order to facilitate secure communication using decentralized identifiers, users may often need to share their DID over an out-of-band connection such as SMS, bluetooth, QR code, etc. Depending on the type and quality of the connection, this step may prove to be a vulnerability if the connection is compromised.

This is exactly why we added DID Rotation to DIDComm v2, which allows you to rotate away from the potentially exposed DID to a new private one not passed over an observable connection. How should we update the text to reflect the elimination of that issue?

[creatornader]

@TelegramSam Just added a section to address this https://github.com/w3c/did-use-cases/pull/132

[philarcher]

@jandrieu and I have discussed this today. We're not looking for new Focal Use cases at this late stage so we thought about reducing this one to a short use case and moving it further up. In the process of doing this, we realized that we already have a requirement: 19. Cryptographic authentication and communication These identifiers enable cryptographic techniques to authenticate individuals and to secure communications with the subject of the identifier, typically using public-private key pairs.

This is cited by 5 existing use cases. However, we noticed that this was not true of the encrypted data vault use case which was an oversight. Thank you for bringing this up. We have corrected this now and, as a result, are more convinced that the requirement for secure communication is made clear in the use cases.

Therefore, we do not plan to merge this PR.

[jandrieu]

Just to be clear, we would welcome a DID Comm use case that describes in human terms a NEW value-creating interaction that DIDs enable. The paragraph on Samir is exactly the kind of thing we are looking for, but the supplier/customer confidential communication is already covered in Section 2.3's story of Maria using DIDs for confidential customer engagement, so we couldn't see how the story in this PR demonstrates a new feature.

[creatornader]

The new value for humans is that DIDs enable us to have a shared protocol that can do consumer messaging (aka private chat) as well as app-based or system-driven communications with things like signing forms and sending authorizations and referrals. It's also specifically about the resilience and usability provided by DIDs as identifiers over phone numbers for humans taking advantage of secure messaging. See: Samira communicating across jurisdictions without censorship, losing her phone and still being able to continue communicating with all of her connections -- both humans and systems alike.

I don't see how this is covered by anything currently in the DID use cases doc, including the requirement you linked to (which is a prerequisite for the use case described in this PR and a requirement that I explicitly included in 'reqList'). It feels like you singled in on a particular line or two of the use case instead of reading through the use case's intent, motivation, and challenges. There are obviously specific elements here that overlap with some of the other use cases because we're building on the same set of requirements, but IMO this one is describing something fundamentally different and emergent. I'd buy that this a matter of finding out how to place emphasis on the right thing but not that the use case as a whole is invalid or completely redundant.

@philarcher seemed like we were on the same page until now. Perhaps the later stage updates muddled the point of the original PR.

[dhh1128]

I agree with @creatornader's response above. We have something like WeChat that is currently used for human-friendly chat, but that also exposes a programmatic API. Nader's use case is for a single DID-based mechanism to be used for both, so humans and automation can interact seamlessly. I don't believe this is described elsewhere.

[TelegramSam]

You've stated that you have no intention of merging this PR. I'd like to make a case for reversing your decision.

Of the cases currently described in the document, only one of them addresses the need for rich interaction and long-term relationships. Alice Rents a Car includes phrases like 'secure communication channel' and phrases like 'tells Alice’s agent' but avoids any other details about how to enable such a thing.

In fact, every single case already included would be made more complete and a better benefit to the user with the inclusion of DIDComm in the interaction. I'll detail each if you desire.

DIDComm enables a secure ongoing relationship, not just a single interaction. Using just a DID and it's resolved DID Document, DIDComm builds a foundation for the development of protocols that preserve user privacy and enable rich user experiences.

This document is about user use cases and direct user benefit. I'll admit that the user benefit of DIDComm is harder to see than the direct examples described above. I will argue that the indirect benefit makes it worth including.

The direct benefit of DIDComm is not to the user, but to the DID using Developer in the form of a strong foundation for interoperable, privacy-preserving protocols. Developer utilization of DIDComm translates into an indirect benefit to the user for improved user experiences. Ongoing relationships become easier to manage. Rich interactions become possible without repeatedly asking the user to become part of an information flow they authorize.

Why are we working so hard to create an addition that you'll understand and include in this document? We care about the rich and streamlined experiences that users need. Not including DIDComm makes it easy to ignore in the future development of the DID Core spec, to the detriment of the developers who will use it, and the users who will benefit.

So, what'll it be? What can we improve about @creatornader's excellent submission that will make it a worthy inclusion? Please let us know.

[awoie]

I'm +1 for merging this PR. IMO, the messaging, routing and rotation part is unique and convincing enough to have its own use case. Just because there is one other use case in the document that includes secure communication already, does not mean the one proposed by @creatornader is invalid or redundant. We have a couple of use cases that mention overlapping tech (e.g., credentials) in their description but they all have their own focus and are all absolutely valid as well in the same way as this PR is valid.

[philarcher]

OK, I hear you, thanks. @jandrieu and I will, I hope, speak at the end of the week and work out the way forward.

[jandrieu]

@telegramsam and @awoie The problem is that DIDComm itself is not a a real-world problem that DIDs solve. DIDComm is built on top of DIDs, not the other way around.

So, once we remove the term "DIDComm" from the narrative, in an attempt to isolate the unique use case that this PR enbles, we found that the description no longer described something new enough to add to the use cases.

@creatornader said:

The new value for humans is that DIDs enable us to have a shared protocol that can do consumer messaging (aka private chat) as well as app-based or system-driven communications with things like signing forms and sending authorizations and referrals.

Arguably, email does exactly that. Just the other day I "signed" a contract with my email address and sent it over email.

Sure, that email isn't cryptographically secured, but that is a distinction already discussed. DIDS allow cryptographically secure communications, as well described in Section 2.3 Encrypted Data Vault. It is also indirectly covered in 2.6, 2.7, 2.8, and 6.6.

If there are elements missing from those use cases which would better highlight what you are trying to include, please suggest an addition to those use cases.

Our goal at this stage is not to add new use cases. Our goal is to ensure that the use cases we have capture the essential uses that DIDs were created for.

@TelegramSam said

Not including DIDComm makes it easy to ignore in the future development of the DID Core spec, to the detriment of the developers who will use it, and the users who will benefit.

Unfortunately, DIDComm is not suitable for inclusion as it is a derivative from DIDs rather than an illustration of why we need DIDs. We aren't creating DIDs because we can't do DID Comm without them. Just as we aren't creating DIDs because we can't do DID Auth without them.

We are creating DIDs because they allow us to solve real-world problems that weren't otherwise solvable. If there is a new example of real-world problems--or an extension to existing examples--that shows how DIDs solve real-world problems, we are open to that.

A personal concern I have with this (and related issues and PRs) is that it seems that many are arguing for the literal inclusion of DIDComm in the DID Use Cases document. @TelegramSam's specifically calls out that "Not including DIDComm" [is a problem]. This would not be appropriate and neither of the current editors is inclined to embed specific technical solutions in this document. Those specifics belong either in did-core or in a subsequent publication.

I see that @philarcher replied while I was typing this up. We'll sync up and discuss.

[awoie]

A personal concern I have with this (and related issues and PRs) is that it seems that many are arguing for the literal inclusion of DIDComm in the DID Use Cases document. @TelegramSam's specifically calls out that "Not including DIDComm" [is a problem]. This would not be appropriate and neither of the current editors is inclined to embed specific technical solutions in this document. Those specifics belong either in did-core or in a subsequent publication.

@jandrieu I don't understand the issue with DIDComm. We mention Verifiable Credentials and we even mention Encrypted Data Vaults which is not a W3C standard either (see https://w3c.github.io/did-use-cases/#edv). I don't think that the group had an issue with being more specific to technical terms yet. Furthermore, the use case doc is non-normative anyways.

[agropper]

I support @jandrieu perspective on DIDcomm as a use-case. Encrypted Data Vaults are not at all dependent on DIDs any more than GNAP is dependent on DIDs. I appreciate the value of transport-neutral protocols but I don't see how DIDs as a standard have anything to do with that.

On Mon, Jan 4, 2021 at 1:08 PM Oliver Terbu notifications@github.com wrote:

A personal concern I have with this (and related issues and PRs) is that it seems that many are arguing for the literal inclusion of DIDComm in the DID Use Cases document. @TelegramSam https://github.com/TelegramSam's specifically calls out that "Not including DIDComm" [is a problem]. This would not be appropriate and neither of the current editors is inclined to embed specific technical solutions in this document. Those specifics belong either in did-core or in a subsequent publication.

@jandrieu https://github.com/jandrieu I don't understand the issue with DIDComm. We mention Verifiable Credentials and we even mention Encrypted Data Vaults which is not a W3C standard either (see https://w3c.github.io/did-use-cases/#edv). I don't see that the group had an issue with being more specific to technical terms yet.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/did-use-cases/pull/126#issuecomment-754128258, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YJTONOEHIAHVEK5VMTSYH7X7ANCNFSM4UWS5Y4A .

[awoie]

@TelegramSam and @awoie The problem is that DIDComm itself is not a a real-world problem that DIDs solve. DIDComm is built on top of DIDs, not the other way around.

Messaging is a real world use case and DIDs can be a great solution for distributing (and managing through rotation) the public key material needed for establishing a secure communication channel. IMO, whether or not DIDComm is built on top is a subjective observation.

So, once we remove the term "DIDComm" from the narrative, in an attempt to isolate the unique use case that this PR enbles, we found that the description no longer described something new enough to add to the use cases.

@creatornader said:

The new value for humans is that DIDs enable us to have a shared protocol that can do consumer messaging (aka private chat) as well as app-based or system-driven communications with things like signing forms and sending authorizations and referrals.

Arguably, email does exactly that. Just the other day I "signed" a contract with my email address and sent it over email.

Email does not address that problem entirely and is limited in scope. Personally, I don't think it is a great approach to use email for higher level protocols either, e.g., credentials exchange. S/MIME relies on central authorities and imo, PGP is "dead". That is why something new is needed -> DIDComm.

Sure, that email isn't cryptographically secured, but that is a distinction already discussed. DIDS allow cryptographically secure communications, as well described in Section 2.3 Encrypted Data Vault. It is also indirectly covered in 2.6, 2.7, 2.8, and 6.6.

We have multiple overlapping references of other tech as well, so I don't see this as a reason to not merge this PR.

If there are elements missing from those use cases which would better highlight what you are trying to include, please suggest an addition to those use cases.

Our goal at this stage is not to add new use cases. Our goal is to ensure that the use cases we have capture the essential uses that DIDs were created for.

People from the DIDComm community believe that one of them is DIDComm. I believe that this PR perfectly captures the DIDComm use case, extending/changing existing ones makes less sense to me.

[awoie]

I support @jandrieu perspective on DIDcomm as a use-case. Encrypted Data Vaults are not at all dependent on DIDs any more than GNAP is dependent on DIDs. I appreciate the value of transport-neutral protocols but I don't see how DIDs as a standard have anything to do with that.

My apologies, I quoted the wrong spec. It should have been this: https://digitalbazaar.github.io/encrypted-data-vaults/. My point was that EDVs are a specific technical term as well.

[creatornader]

@jandrieu you mentioned the following:

A personal concern I have with this (and related issues and PRs) is that it seems that many are arguing for the literal inclusion of DIDComm in the DID Use Cases document. @TelegramSam's specifically calls out that "Not including DIDComm" [is a problem]. This would not be appropriate and neither of the current editors is inclined to embed specific technical solutions in this document. Those specifics belong either in did-core or in a subsequent publication.

I am personally uninterested in the political motivations associated with "including DIDComm in the DID Use Cases document" at all costs. As the person who wrote it, that's far from the point of this PR. On the contrary, I mentioned it as an example of how DIDs can be used to solve the difficult problem of secure messaging in a robust and resilient way. Again, I think that this use case stands on its own merit, regardless of meta-discussions about "whether or not we should include DIDComm" specifically by explicit reference. It's not critical path and I'm not sure why we keep coming back to this point when IMO the PR can live with or without the direct link to DIDComm. Changes welcome.

Agreed on all @awoie's points above.

This PR meets the criteria of: 1) solving a problem not already present in the use cases doc 2) improving upon existing real world solutions to the problem 3) providing real human value to people using DIDs as the core mechanism

I believe all of these need to be evaluated in tandem. It's very easy to deem something redundant if you choose to isolate or ignore any of the above points, right? Please help me understand what I'm missing here. That's besides the fact that, as both editors mentioned several times, you're no longer "adding new use cases." That reads to me like any PR introducing a new use case will be rejected on principle at this point in time pretty much regardless of content. If that's the case, then I suppose the discussion is over.

[jandrieu]

@creatornader wrote [all quotes are from @creatornader] :

I am personally uninterested in the political motivations associated with "including DIDComm in the DID Use Cases document" at all costs.

This isn't political, it's about whether or not advocates in this thread are working to get the term "DIDComm" into the use case document. That's a non-starter. I mention that for two reasons:

1. In case that is the goal of anyone's advocacy, it would be helpful to drop it.
2. Arguments to "include DIDComm" aren't going to move the needle on this one. Describe your arguments for specific text without a priori reference to DIDComm you will have a greater chance to influence the document.

Changes welcome.

As described previously, when the editors discussed the proposed PR, we walked through what would remain from the text once we removed DID Comm references. When we did that, there wasn't enough in the text to distinguish the PR from ideas already illustrated by other use cases.

If you can update your PR to remove DID Comm references and still present a distinct use case, we will consider it. It's not our job to do that writing for you.

This PR meets the criteria of:

• solving a problem not already present in the use cases doc

As already said, we see significant overlap with Section 2.3 Encrypted Data Vault. It is also indirectly covered in 2.6, 2.7, 2.8, and 6.6.

That's besides the fact that, as both editors mentioned several times, you're no longer "adding new use cases." That reads to me like any PR introducing a new use case will be rejected on principle at this point in time pretty much regardless of content. If that's the case, then I suppose the discussion is over.

The editors would like to finish this document. At some point we have to stop the process of adding new use cases. That is a motivating factor, and this particular use case is one that we have kept open for consideration because we value the work that DIDComm is bringing to the ecosystem. However, we haven't had much success with our requests for a distinctive use case that presents the real-world challenges addressed by DIDComm without relying on DIDComm for justification. We have put significant time in our own calls trying to make this work and we did not see a way to do that. If we were earlier in the process, we might have more cycles to drive original copywriting but we aren't.

[jandrieu]

@awoie wrote:

@TelegramSam and @awoie The problem is that DIDComm itself is not a a real-world problem that DIDs solve. DIDComm is built on top of DIDs, not the other way around.

Messaging is a real world use case and DIDs can be a great solution for distributing (and managing through rotation) the public key material needed for establishing a secure communication channel.

Agreed. And already covered by several existing use cases. If something is missing from those, I expect a sentence or so would work better than a new use case. The reality is that secure messaging can be accomplished in many ways other than DIDComm. The editors' concern isn't with "secure messaging" it is with the repeated requests to include "DIDComm" specifically.

IMO, whether or not DIDComm is built on top is a subjective observation.

It isn't a subjective observation to the editors. DID Comm does not work without DIDs. While DIDs do work without DIDComm. The order of dependency is clear to us.

Email does not address that problem entirely and is limited in scope. Personally, I don't think it is a great approach to use email for higher level protocols either, e.g., credentials exchange. S/MIME relies on central authorities and imo, PGP is "dead". That is why something new is needed -> DIDComm.

Agreed. DIDComm does a lot more than what email does. However, the specific text that was referenced can be satisfied with email.

The devil here is in the details. I think it was @creatornader who said that what is most interesting is the simultaneous use of the same identifier for both communications and cryptographic security. THAT is interesting, and maybe it isn't clear from existing use cases. Whether or not updating a current use case or adding a new one is better is as much a style decision as anything. HOWEVER, the current text (a) has a bunch of implementation details (DIDCOMM) and (b) it did not concisely describe that as the fundamental thing that DIDs bring to the table. Rather, what it presents as advocacy of DIDComm as a solution rather than an illustration of the problems that DIDComm solves that DIDs should solve too. It is this advocacy that is inappropriate here.

We have multiple overlapping references of other tech as well, so I don't see this as a reason to not merge this PR.

To your point about EDVs: we would welcome a PR that proposes an alternative term. However, it is worth noting that the EDV spec itself does not depend on DIDs. From the spec:

1.4.3 Identifiers The system should be identifier agnostic. In general, identifiers that are a form of URN or URL are preferred. While it is presumed that DIDs will be used by the system in a few important ways, hard-coding the implementations to DIDs would be an anti-pattern.

In contrast, DIDComm has baked DIDs into its implementation. In fact, at least in RFC5, it bakes in some very specific did solution details (such as looking up a DID Document).

The editors have gone to great lengths to reduce the solution specific language throughout. DIDComm references undermine that.

@awoie wrote:

Our goal at this stage is not to add new use cases. Our goal is to ensure that the use cases we have capture the essential uses that DIDs were created for.

People from the DIDComm community believe that one of them is DIDComm. I believe that this PR perfectly captures the DIDComm use case, extending/changing existing ones makes less sense to me.

I'm not sure how to address this misperception. But I'll try.

DIDs came out of VC work. DIDComm came out of the DID work. DID Comm did not exist prior to the first published DID paper in 2016: https://github.com/WebOfTrustInfo/rwot2-id2020/blob/master/final-documents/requirements-for-dids.pdf In fact, you'll note that there is no mention of either "messag" or "comm". While the DID creators undoubtedly understood the cryptographic capabilities of DIDs would enable a broad range of use cases, DID Comm was not a real-world problem that DIDs were created for. It couldn't be, because it didn't exist when DIDs were created.

The earliest reference I can find to DID Comm claims

Start Date: 2018-01-05 (approx, backdated)

As an active member of the larger community that created VCs and DIDs, I can personally warrant that those early conversations were not based on satisfying an existing approach known as DIDComm.

That said, the problems that DID Comm is trying to solve are absolutely fair game, and secure messaging is one of those. However, when the editors attempted to update this PR to (1) fit into a concise use case rather than a focal use case and (2) remove the DIDComm specifics, we ended up with a paragraph that simply repeated features found in other examples.

If we can turn this into a simple paragraph that illustrates features or requirements that are lacking in other use cases without mentioning DIDComm, we can work with that. A long form focal use case that promotes a specific DID-dependent technology without introducing distinctive features or requirements is not going to meet muster.

[awoie]

@jandrieu Thanks for the clarification, comments below ...

Agreed. And already covered by several existing use cases. If something is missing from those, I expect a sentence or so would work better than a new use case. The reality is that secure messaging can be accomplished in many ways other than DIDComm. The editors' concern isn't with "secure messaging" it is with the repeated requests to include "DIDComm" specifically.

Agree that there are other means to implement "secure messaging". Though, imo, secure messaging is a use case by itself. 2 billion WhatsApp users would agree with me. But even Whatsapp, Signal and so on have either issues with censorship, relying on existing social graphs, users are not in control over their identifier and/or use central components.

Email does not address that problem entirely and is limited in scope. Personally, I don't think it is a great approach to use email for higher level protocols either, e.g., credentials exchange. S/MIME relies on central authorities and imo, PGP is "dead". That is why something new is needed -> DIDComm.

Agreed. DIDComm does a lot more than what email does. However, the specific text that was referenced can be satisfied with email.

I partially agree because I believe using emails you would still rely on your email address and therefore on ICANN/DNS (central authority).

The devil here is in the details. I think it was @creatornader who said that what is most interesting is the simultaneous use of the same identifier for both communications and cryptographic security. THAT is interesting, and maybe it isn't clear from existing use cases. Whether or not updating a current use case or adding a new one is better is as much a style decision as anything. HOWEVER, the current text (a) has a bunch of implementation details (DIDCOMM) and (b) it did not concisely describe that as the fundamental thing that DIDs bring to the table. Rather, what it presents as advocacy of DIDComm as a solution rather than an illustration of the problems that DIDComm solves that DIDs should solve too. It is this advocacy that is inappropriate here.

We have multiple overlapping references of other tech as well, so I don't see this as a reason to not merge this PR.

To your point about EDVs: we would welcome a PR that proposes an alternative term.

I'm not arguing for changing it, I just assumed because EDV is mentioned, DIDComm would not be a problem either.

@awoie wrote:

Our goal at this stage is not to add new use cases. Our goal is to ensure that the use cases we have capture the essential uses that DIDs were created for.

Alright, I just assumed that adding new use cases (especially less VC-focused) would be a great add-on for the UC doc. Especially, since the DID WG charter calls out that UCs from other industries may be included : "Concentrate their efforts on the initial use cases with a particular focus on enabling future specification and implementation of Identity and Access Management. Use cases from other industries may be included if there is significant industry participation."

I'm not sure how to address this misperception. But I'll try.

DIDs came out of VC work. DIDComm came out of the DID work. DID Comm did not exist prior to the first published DID paper in 2016: https://github.com/WebOfTrustInfo/rwot2-id2020/blob/master/final-documents/requirements-for-dids.pdf In fact, you'll note that there is no mention of either "messag" or "comm". While the DID creators undoubtedly understood the cryptographic capabilities of DIDs would enable a broad range of use cases, DID Comm was not a real-world problem that DIDs were created for. It couldn't be, because it didn't exist when DIDs were created.

I agree with that observation and thanks for pointing that out. Though, see my comment above on UC from other industries that may be included.

As an active member of the larger community that created VCs and DIDs, I can personally warrant that those early conversations were not based on satisfying an existing approach known as DIDComm.

Agree but see comment above.

That said, the problems that DID Comm is trying to solve are absolutely fair game, and secure messaging is one of those. However, when the editors attempted to update this PR to (1) fit into a concise use case rather than a focal use case and (2) remove the DIDComm specifics, we ended up with a paragraph that simply repeated features found in other examples.

IMO, already the "background section" is distinct from other UCs and outlines some of the downsides that existing messaging systems have which DIDComm tries to address. The PR also talks about connection management, service discovery, routing, key rotation and recovery which have not been possible so far without using DIDs (at least not without a central system). I didn't see this in any other UC. But I agree that this could be part of most (all?) of the UCs.

If we can turn this into a simple paragraph that illustrates features or requirements that are lacking in other use cases without mentioning DIDComm, we can work with that. A long form focal use case that promotes a specific DID-dependent technology without introducing distinctive features or requirements is not going to meet muster.

Again, after seeing references to VCs and EDVs I didn't assume there was an issue with DIDComm being explicitly mentioned but it seems to be a concern for some people.

@jandrieu Is my assumption correct that the group would object to including the term DIDComm regardless of the UC itself? Further, do you agree/recognize that secure p2p messaging (communication) can be a focal UC by itself? Because even without mentioning DIDComm it would still be valuable to include this PR.

[TallTed]

@creatornader @TelegramSam @awoie --

Your challenge at this point (which happens to be late in the process for the UC document) is to present a use case which demands (either requires or would be improved substantially by) DIDs, which might well be secure p2p messaging, without uttering "DIDComm" therein.

For this to be a new use case in the current document, it must differ substantially from all existing use cases. If it's at all close to an existing use case, then that case should be edited to include/allow-for the new feature(s)/variation(s) that make your use case special/different. Several existing use cases have already been cited as being very close to yours, once "DIDComm" as such is removed, so I would suggest you focus on merging your feature(s) into the closest case you see.

Weeks or months from now, DIDComm might then serve as one of the two necessary [1] implementations of the secure messaging feature(s) of DIDs, but "DIDComm" as such doesn't belong in the use case itself, nor in the DID Core spec, and possibly not in any spec currently planned to emerge from the DID WG.

[1] "Necessary" here is to have that feature included in an eventual TR. Lacking two implementations of any feature is grounds to drop that feature from the spec.

[jandrieu]

@philarcher and I discussed this today and would like to suggest the following use case, to be included in the regular use case section:

Secure Messaging Samira works as a therapist. When she meets a new client, she establishes a secure connection with them by having them scan a QR code to pass on her DID and start sharing messages. Messages are secured via mutual authentication between Samira and her clients. Using this connection, Samira is able to have private and confidential communications with her clients at any time. Her clients are able to have confidence that they’re talking to Samira, and Samira is able to tell whether she is speaking to a client, or, if delegated by the client, communicating with their spouse or children. Using the same secure connection, clients can utilize different protocols to sign and send forms such as medical releases and Samira can share credentials with her clients to prove she has a valid board certification.

If that works for everyone, @philarcher will turn it into a PR and we'll add it to the doc.

[agropper]

We're on the right track but this use-case is underspecified. Lots of use-cases start with a service provider displaying a QR code to a client. This is the basis for almost all COVID-entry apps, for example. The restaurant (service) posts a QR code that is not specific to any particular encounter and expects a client to use their mobile camera to provide some personal contact information. Let's call this 'Registration".

That's a complete use-case.

We can then enhance the Registration use-case where either the client or the restaurant wants to message the other about some COVID-related thing. This is almost certainly not going to use QR codes. The transport and protocol for the message would have been registered during the Registration.

I suggested a similar use-case as https://github.com/w3c/did-use-cases/issues/113 Maybe we should combine them.

Adrian

On Fri, Jan 8, 2021 at 11:48 AM Joe Andrieu notifications@github.com wrote:

@philarcher https://github.com/philarcher and I discussed this today and would like to suggest the following use case, to be included in the regular use case section:

Secure Messaging Samira works as a therapist. When she meets a new client, she establishes a secure connection with them by having them scan a QR code to pass on her DID and start sharing messages. Messages are secured via mutual authentication between Samira and her clients. Using this connection, Samira is able to have private and confidential communications with her clients at any time. Her clients are able to have confidence that they’re talking to Samira, and Samira is able to tell whether she is speaking to a client, or, if delegated by the client, communicating with their spouse or children. Using the same secure connection, clients can utilize different protocols to sign and send forms such as medical releases and Samira can share credentials with her clients to prove she has a valid board certification.

If that works for everyone, @philarcher https://github.com/philarcher will turn it into a PR and we'll add it to the doc.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/did-use-cases/pull/126#issuecomment-756865141, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YLIOC4OENLDFIN3LCTSY4ZPDANCNFSM4UWS5Y4A .

[TallTed]

@agropper --

We're on the right track but this use-case is underspecified. Lots of use-cases start with a service provider displaying a QR code to a client. This is the basis for almost all COVID-entry apps, for example. The restaurant (service) posts a QR code that is not specific to any particular encounter and expects a client to use their mobile camera to provide some personal contact information. Let's call this 'Registration".

That's a complete use-case.

Uh... I don't see "a complete use-case" here. I see some comment about an "underspecified" use-case, some reference to unrelated scenarios, and something that appears intended to embellish the initially-mentioned "underspecified" use-case but also appears to include at least one error (I think mobile camera in the above should be mobile phone).

We can then enhance the Registration use-case where either the client or the restaurant wants to message the other about some COVID-related thing. This is almost certainly not going to use QR codes. The transport and protocol for the message would have been registered during the Registration.

I suggest and request that you submit a complete and actionable revision of the previous suggestion which you called incomplete, along with a complete and actionable rewording delivering the "enhancement" of the use-case you suggest should be "enhanced" (with? by? replacing?) the just-mentioned revision.

I am asking for these complete texts because it is clear that I (and I believe others) are not understanding your less-contextualized suggestions, leading to much back-and-forth with little actual progress.

[agropper]

Fair enough:

Secure Messaging Samira works as a therapist. When she meets a new client, Alice, she establishes a secure connection with them by having them scan a QR code using their mobile phone to pass on her DID and enable sharing messages. Messages are secured via mutual authentication between Samira and her clients. Alice registers a service endpoint that can be used for authenticating her and an inbox for messages. Using this connection, Samira is able to have private and confidential communications with Alice at any time. Alice is able to have confidence that they’re talking to Samira, and Samira is able to tell whether she is speaking to Alice, or, if delegated by Alice, communicating with their spouse or children. Using the same secure connection, Alice can utilize different protocols to sign and send forms such as medical releases. Samira can share credentials with her clients to prove she has a valid board certification. Depending on Alice's preference, Samira might need to share her board certification before Alice lets her have access to her inbox. Conversely, Smaira might ask Alice for proof of insurance before exposing her inbox to Alice.

On Fri, Jan 8, 2021 at 4:17 PM Ted Thibodeau Jr notifications@github.com wrote:

@agropper https://github.com/agropper --

We're on the right track but this use-case is underspecified. Lots of use-cases start with a service provider displaying a QR code to a client. This is the basis for almost all COVID-entry apps, for example. The restaurant (service) posts a QR code that is not specific to any particular encounter and expects a client to use their mobile camera to provide some personal contact information. Let's call this 'Registration".

That's a complete use-case.

Uh... I don't see "a complete use-case" here. I see some comment about an "underspecified" use-case, some reference to unrelated scenarios, and something that appears intended to embellish the initially-mentioned "underspecified" use-case but also appears to include at least one error (I think mobile camera in the above should be mobile phone).

We can then enhance the Registration use-case where either the client or the restaurant wants to message the other about some COVID-related thing. This is almost certainly not going to use QR codes. The transport and protocol for the message would have been registered during the Registration.

I suggest and request that you submit a complete and actionable revision of the previous suggestion which you called incomplete, along with a complete and actionable rewording delivering the "enhancement" of the use-case you suggest should be "enhanced" (with? by? replacing?) the just-mentioned revision.

I am asking for these complete texts because it is clear that I (and I believe others) are not understanding your less-contextualized suggestions, leading to much back-and-forth with little actual progress.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/did-use-cases/pull/126#issuecomment-757002470, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YOACUSSUODXNNNBCY3SY5Y7VANCNFSM4UWS5Y4A .

[TelegramSam]

I like the general approach here, but I'm not sure the "Alice registers a service endpoint that can be used for authenticating her and an inbox for messages." part belongs.

[TelegramSam]

@philarcher and I discussed this today and would like to suggest the following use case, to be included in the regular use case section:

Secure Messaging Samira works as a therapist. When she meets a new client, she establishes a secure connection with them by having them scan a QR code to pass on her DID and start sharing messages. Messages are secured via mutual authentication between Samira and her clients. Using this connection, Samira is able to have private and confidential communications with her clients at any time. Her clients are able to have confidence that they’re talking to Samira, and Samira is able to tell whether she is speaking to a client, or, if delegated by the client, communicating with their spouse or children. Using the same secure connection, clients can utilize different protocols to sign and send forms such as medical releases and Samira can share credentials with her clients to prove she has a valid board certification.

If that works for everyone, @philarcher will turn it into a PR and we'll add it to the doc.

I like this as written @jandrieu .

[dhh1128]

I think the proposal is headed in the right direction, and I could vote for it to be merged as-is, if need be. However, I would like to explain why I think it misses some nuances. I know I should make a concrete counter-proposal, but I am really struggling to get out from under a crushing to-do list before my job changes in a week, so please tolerate the meditation without a specific proposal. I'm hoping what I say will spark someone to do one final editing pass. If it doesn't, maybe I can come back in 10 days or so and offer something.

The use case as pared down by Adrian et al. assumes a context (Samira and her clients wanting to exchange private, confidential messages) and THEN talks about features within that context. This is not wrong, and it does illustrate a use of DIDs that can be solved by DIDComm or other techniques that are DID-related. But the fact that it assumes the limited context first is a missed opportunity to teach, and I think that's why Nader's original version was broader. Within a single context, secure messaging feels boring, and security-through-DIDs has lots of almost-as-good alternatives. It's cross-context scenarios that get more interesting. Nader had these in his original version, but I'd like to offer my own explanation of why.

The reason DIDs as the basis of secure communication [DIDComm, or anything like unto it] is so compelling to me is that DIDs take control over security out of the hands of the context owner, and puts it in the hands of the DID controller, who can choose any number of contexts. This makes security decentralized and portable. This is a potential benefit of DIDs generally, not limited to DIDComm. It is a reason for DIDs to be invented, all on its own. If DIDs provide the security for communication -- not TLS, not the Signal protocol, not Facebook -- then the security is no longer tied to the protocol, or the transport, or the application, or any other contextual ingredient that carries it in a pre-DID world; it's tied to DID controllership itself. And DID controllership is decentralized and self-serve, whereas control over other variables of our interactions is not, today. This means that for the first time, you can switch contexts without losing security.

In a traditional secure messaging approach (WeChat or WhatsApp or Signal or Facebook Messenger or S/MIME or Slack or iMessage or ...), the security is a property of the platform; change platforms, and we get your security a different way, tied to a different login and different terms of service. To get security or privacy, we accept vendor lock-in. (Yes, we can get another vendor to give us security another way, but we can't get another vendor to give us security the same way, using the same keys.) Nader perhaps had this in mind when he came up with so many different contexts for Samira to communicate -- but because he didn't hold the interaction partner constant across all his scenarios, perhaps this wasn't obvious. I think we should hold the interaction partner for Samira constant, but vary the contexts dramatically to make this clear. I also think we should stop calling the scenario "Secure Messaging" and instead call it something like "Portable Secure Interactions." The emphasis is on the word "Portable", not the word "Secure". That's what's new and compelling. ("Interactions" is the second most important word, because it implies that it goes well beyond the simple exchange of messages.)

Suppose Samira is communicating using DIDComm (or any other incarnation of DID-based secure comm), with email as the transport. She can switch to using SMS as the transport, and the security doesn't change. She is still known to be Samira, and her clients are still known to be who they were in the other context. The identities of the parties, plus all the confidential and integrity guarantees -- and the important security values themselves, the keys and policies and encryptions -- are identical. There is no new login, and there is also no new chat history or context for the relationship. The context is tied to the DIDs, not the channel. Samira can go back and forth between email and SMS, seamlessly. This matches the way humans want to behave: with our Mom, we naturally have fragments of a conversation by text, fragments by phone, fragments by Facetime.

The context switching doesn't stop with email vs. SMS; Samira can go offline and do everything by BlueTooth, and it still works. Heck, she can move to snail mail and send encrypted messages on paper if she wants. And she can keep switching back and forth, as much as she wants. The provider of any given channel that Samira selects can't lock in the participants by requiring them to stay in the channel to keep the security. And as Nader's example attempted to show, Samira can switch interaction types and keep the same security, too. Maybe she needs to go beyond exchanging secure messages with patient X; now she wants to collect consent to participate in a research study. So she switches from free-form chat to a Docusign-type workflow, but still the same security. Or maybe now she wants to get a bill paid. Instead of humans chatting, now Samira's accounts receivable system and Alice's bill pay feature at the bank interact -- but still use the same security. Or Maybe Samira wants to schedule a procedure at the hospital. It can still be the same keys, the same identity, the same context, the same history. Maybe Samira wants to conduct a telehealth session. It's still the same security. Before DIDs, every one of these could be done securely, but every aspect of these interactions was a silo. Yes, you could attempt SSO -- but there were always systems that didn't fit. With DIDs, there is one thing guaranteed to be common across all contexts, and that is the DID controller themself. DIDs let us associate the security with that guaranteed commonality. This is big.

Does that break any logjams, or did I just ramble on?

[agropper]

+1 Daniel. I believe my suggestion said what you are saying.

The only gap where I may have missed your perspective is "Using the same secure connection..." which could be interpreted to mean that Samira and Alice are tied to the same platform or transport. I meant "connection' to be their mutual "registration" of each other's DID. So, I might change the word "connection" to "registration" in order to avoid that bit of confusion.

I described registration as involving a service endpoint because the service endpoint of a DID can be changed by the controller if they choose to alter the transport or protocol to reach their inbox (or the authorization server that controls access to their inbox). I glossed over the question of whether Samira caches the service endpoint or looks it up fresh by resolving the DID each time. To be consistent with @Daniel's description,registration should store only Alice's DID. The reciprocal point applies to Alice's registration of Samira's DID, of course.

I adopted your title and changed one word below to use registration consistently throughout:

Portable Secure Interactions Samira works as a therapist. When she meets a new client, Alice, she establishes a secure connection with them by having them scan a QR code using their mobile phone to pass on her DID and enable sharing messages. Messages are secured via mutual authentication between Samira and her clients. Alice registers a service endpoint that can be used for authenticating her and an inbox for messages. Using this connection, Samira is able to have private and confidential communications with Alice at any time. Alice is able to have confidence that they’re talking to Samira, and Samira is able to tell whether she is speaking to Alice, or, if delegated by Alice, communicating with their spouse or children. Using the same secure registration, Alice can utilize different protocols to sign and send forms such as medical releases. Samira can share credentials with her clients to prove she has a valid board certification. Depending on Alice's preference, Samira might need to share her board certification before Alice lets her have access to her inbox. Conversely, Smaira might ask Alice for proof of insurance before exposing her inbox to Alice.

On Fri, Jan 8, 2021 at 9:16 PM Daniel Hardman notifications@github.com wrote:

I think the proposal is headed in the right direction, and I could vote for it to be merged as-is, if need be. However, I would like to explain why I think it misses some nuances. I know I should make a concrete counter-proposal, but I am really struggling to get out from under a crushing to-do list before my job changes in a week, so please tolerate the meditation without a specific proposal. I'm hoping what I say will spark someone to do one final editing pass. If it doesn't, maybe I can come back in 10 days or so and offer something.

The use case as pared down by Adrian et al. assumes a context (Samira and her clients wanting to exchange private, confidential messages) and THEN talks about features within that context. This is not wrong, and it does illustrate a use of DIDs that can be solved by DIDComm or other techniques that are DID-related. But the fact that it assumes the limited context first is a missed opportunity to teach, and I think that's why Nader's original version was broader. Within a single context, secure messaging feels boring, and security-through-DIDs has lots of almost-as-good alternatives. It's cross-context scenarios that gets more interesting. Nader had these in his original version, but I'd like to offer my own explanation of why.

The reason DIDs as the basis of secure communication [DIDComm, or anything like unto it] is so compelling to me is that they take control over security out of the hands of the context owner, and puts it in the hands of the DID controller, who can choose any number of contexts. This makes security decentralized and portable. This is a potential benefit of DIDs generally, not limited to DIDComm. It is a reason for DIDs to be created, all on its own. If DIDs provide the security for communication -- not TLS, not the Signal protocol, not Facebook -- then the security is no longer tied to the protocol, or the transport, or the application, or any other contextual ingredient that carries it in a pre-DID world; it's tied to DID ownership itself. And DID ownership is decentralized and self-serve, whereas control over other variables of our interactions is not, today. This means that for the first time, you can switch contexts without losing security.

In a traditional secure messaging approach (WeChat or WhatsApp or Signal or Facebook Messenger or S/MIME or Slack or iMessage or ...), the security is a property of the platform; change platforms, and we get your security a different way, tied to a different login and different terms of service. To get security or privacy, we accept vendor lock-in. (Yes, we can get another vendor to give us security another way, but we can't get another vendor to give us security the same way, using the same keys.) Nader perhaps had this in mind when he came up with so many different contexts for Samira to communicate -- but because he didn't hold the interaction partner constant across all his scenarios, perhaps this wasn't obvious. I think we should hold the interaction partner for Samira constant, but vary the contexts dramatically to make this clear. I also think we should stop calling the scenario "Secure Messaging" and instead call it something like "Portable Secure Interactions."

Suppose Samira is communicating using DIDComm (DID security properties in any incarnation, really) as the security and email as the transport. She can switch to using SMS as the transport, and the security doesn't change. She is still known to be Samira, and her clients are still known to be who they were in the other context. The identities of the parties, plus all the confidential and integrity guarantees -- and the important security values themselves, the keys and policies and encryptions -- are identical. There is no new login, and there is also no new chat history or context for the relationship. The context is tied to the DIDs, not the channel. Samira can go back and forth between email and SMS, seamlessly. This matches the way humans want to behave: with our Mom, we naturally have fragments of a conversation by text, fragments by phone, fragments by Facetime.

The context switching doesn't stop with email vs. SMS; Samira can go offline and do everything by BlueTooth, and it still works. Heck, she can move to snail mail and send encrypted messages on paper if she wants. The provider of any given channel that Samira selects can't lock in the participants by requiring them to stay in the channel to keep the security. And as Nader's example attempted to show, Samira can switch interaction types and keep the same security, too; maybe she needs not just to exchange secure messages with patient X, but also to collect consent to participate in a research study. No longer freeform chat, but still the same security. Or get a bill paid. No longer humans interacting, but now Samira's accounts receivable system and Alice's bill pay feature at the bank -- but still the same security. Or schedule a procedure at the hospital. Still the same security. Or conduct a telehealth session. Still the same security. Before DIDs, every one of these could be done securely, but every aspect of these interactions was a silo. Yes, you could attempt SSO -- but there were always systems that didn't fit. With DIDs, there is one thing guaranteed to be common across all contexts, and that is the DID controller themself. DIDs let us associate the security with that guaranteed commonality. This is big.

Does that break any logjams, or did I just ramble on?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/did-use-cases/pull/126#issuecomment-757079321, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YNPBKG5DO46MT6R62LSY64AZANCNFSM4UWS5Y4A .

[dhh1128]

@agropper Thanks for proposing something concrete after my long ramble. I like it pretty well, but I don't think it yet makes it clear that the portability crosses channels; right now the emphasis seems to be on portability only across interaction types/protocols.

How would you feel about this tweak?

Your version:

Using this connection, Samira is able to have private and confidential communications with Alice at any time.

My tweak:

Using this connection, Samira is able to have private and confidential communications with Alice at any time, over any convenient communication channel: email, chat, SMS, sneakernet, BlueTooth, etc. Because the security is based on the same DIDs regardless, instead of being provided by the transport, the participants use the same identities and achieve the same privacy and security guarantees across all of them, and the context of their interaction encompasses all the channels together. The security is portable rather than siloed by channel, and the security cannot be centralized or governed by a vendor to achieve lock-in.

[agropper]

I'm totally fine with your tweak.

The point I've been trying to make is that communication starts with an introduction and registration step. Someone makes the first move and both parties have privacy interests. Messaging always brings a risk of spam and a significant cost of having to process an incoming message. The Samira / Alice relationship is pretty symmetrical but that's not always the case.

In the Ambient Surveillance use case https://github.com/w3c/did-use-cases/issues/113 I try to address the problem of asymmetric "mutual authentication". If Samira installs a facial recognition camera instead of posting her QR code, she authenticates Alice but has no way to communicate. That's why Alice needs to display a QR code that Samira's camera can also capture. That effectively registers Alice into Samira's system whether she likes it or not. It's up to Samira to then contact Alice if she really intends the relationship to be mutual.

On Sat, Jan 9, 2021 at 12:31 AM Daniel Hardman notifications@github.com wrote:

@agropper https://github.com/agropper Thanks for proposing something concrete after my long ramble. I like it pretty well, but I don't think it yet makes it clear that the portability crosses channels; right now the emphasis seems to be on portability only across interaction types/protocols.

How would you feel about this tweak?

Your version:

Using this connection, Samira is able to have private and confidential communications with Alice at any time.

My tweak:

Using this connection, Samira is able to have private and confidential communications with Alice at any time, over any convenient communication channel: email, chat, SMS, sneakernet, BlueTooth, etc. Because the security is based on the same DIDs regardless, instead of being provided by the transport, the participants use the same identities and achieve the same privacy and security guarantees across all of them, and the context of their interaction encompasses all the channels together. The security is portable rather than siloed by channel, and the security cannot be centralized or governed by a vendor to achieve lock-in.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/did-use-cases/pull/126#issuecomment-757100024, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YOHT5VJYUA65T7FEKTSY7S2RANCNFSM4UWS5Y4A .

[dhh1128]

Thanks, @agropper . Let's wait and see how others feel about where we've converged. (And thanks for the explanation about asymmetric mutual auth; that's interesting.)

[TallTed]

A few thoughts...

• The use case as written relies on DIDs from the start. It doesn't require they be created now, so much as it requires that they were created some while ago. As I read it, the basic idea is that a therapist needs a way to interact (mostly, communicate) securely with a patient, whether via email, phone, sneaker-net, or otherwise. This requires a way for the patient to confirm that a declared identifier of the therapist is accurate, and a way for the therapist to confirm that a declared identifier of the patient is accurate, and a way for each to encrypt and decrypt messages to and from the other, respectively, while confirming that those messages did originate with the identified therapist/patient. (There's a better way to tell this story; I realize I've skipped ahead to the requirements that story reveals.)

• I think there's too much emphasis on QR codes, which (I think) are just a mechanism being used to communicate a DID. Yes, each participant in these Portable Secure Interactions needs to share their DID with each other participant. There is, however, no requirement they do so via QR code; that's just a "you don't have to type my DID!" shortcut (which, because it's not human-readable, is in fact a potential vector through which bad actors could inject themselves -- possibly without a path to full success, but not without nuisance).

• Saying that each user must "register" something is troublesome. At the least, each user's tools must register something, but the very word "register" is problematic, as it suggests a requirement for a larger investment in tools and/or actions than I believe is the case. The task that's being accomplished by "registration" is, I think, basically "saving sufficient details provided by each correspondent to assure similar security for future communication," something like the "return/sender address" on postal or electronic mail; and if correct, I think such a description of activity should be used instead of "register" (and similar).

• Associated with the last point above, I'm not sure I understand "Alice registers a service endpoint that can be used for authenticating her and an inbox for messages." Possibly this small rephrasing works? "Alice registers a service endpoint that can be used both as an authentication service for herself, and as an inbox for messages." At the same time, "service endpoint" (and "authentication service" for that matter) is not end-user-friendly, which I believe most, if not all, use-case descriptions should be. Finally, I see no need to dictate (nor even suggest) that the authentication service should be the same (provided at the same address? by the same software?) as the inbox service.

• At the end, we've got a couple of requirements of Verified Credentials, which are only tangentially related to Decentralized Identifiers, by virtue of the fact that DIDs might be used to identify various entities involved in those VCs. I'm not sure that these callouts to VC are helpful to this DID use case.

[agropper]

inline...

On Mon, Jan 11, 2021 at 1:26 PM Ted Thibodeau Jr notifications@github.com wrote:

A few thoughts...

-

The use case as written relies on DIDs from the start. It doesn't require they be created now, so much as it requires that they were created some while ago. As I read it, the basic idea is that a therapist needs a way to interact (mostly, communicate) securely with a patient, whether via email, phone, sneaker-net, or otherwise. This requires a way for the patient to confirm that a declared identifier of the therapist is accurate, and a way for the therapist to confirm that a declared identifier of the patient is accurate, and a way for each to encrypt and decrypt messages to and from the other, respectively, while confirming that those messages did originate with the identified therapist/patient. (There's a better way to tell this story; I realize I've skipped ahead to the requirements that story reveals.)

Yes. Although in many cases, we prefer same-domain identifiers to seed an interaction even if we then escalate to less privacy-preserving identifiers. Privacy by default would have all interactions bootstrap from a same-domain identifier.

-

I think there's too much emphasis on QR codes, which (I think) are just a mechanism being used to communicate a DID. Yes, each participant in these Portable Secure Interactions needs to share their DID with each other participant. There is, however, no requirement they do so via QR code; that's just a "you don't have to type my DID!" shortcut (which, because it's not human-readable, is in fact a potential vector through which bad actors could inject themselves -- possibly without a path to full success, but not without nuisance).

Yes. We could mention some NFC, ultrasound, and almost any kind of broadcast medium. The point, I believe, is that we're starting with a broadcast rather than a directed outreach. One entity advertises and another may choose to respond. We are all painfully aware of the problems with advertising and targeted advertising. The cost of processing the advertisement is borne by the recipient so it is often essential that the advertiser incur some significant cost. I would welcome concrete suggestions as to how to improve this in this particular use-case.

-

Saying that each user must "register" something is troublesome. At the least, each user's tools must register something, but the very word "register" is problematic, as it suggests a requirement for a larger investment in tools and/or actions than I believe is the case. The task that's being accomplished by "registration" is, I think, basically "saving sufficient details provided by each correspondent to assure similar security for future communication," something like the "return/sender address" on postal or electronic mail; and if correct, I think such a description of activity should be used instead of "register" (and similar).

The use-case could use "provision" instead of "register". One or both participants takes an action specific to the other and incurs some cost and risk. Your point about "future communications" is important. Registration itself is a one-time event that is purely a cost to both participants. It brings no immediate benefit. The reason I prefer terms like register or provision is because they communicate this two-phase nature of the process that causes you to use the word "future".

-

Associated with the last point above, I'm not sure I understand "Alice registers a service endpoint that can be used for authenticating her and an inbox for messages." Possibly this small rephrasing works? "Alice registers a service endpoint that can be used both as an authentication service for herself, and as an inbox for messages." At the same time, "service endpoint" (and "authentication service" for that matter) is not end-user-friendly, which I believe most, if not all, use-case descriptions should be. Finally, I see no need to dictate (nor even suggest) that the authentication service should be the same (provided at the same address? by the same software?) as the inbox service.

Authentication and registration does not require a service endpoint. did:key can work perfectly well for authentication and mutual authentication. The service or service endpoint comes into play when there's a transaction linked to the introduction of the parties. I agree that we should not dictate nor even suggest that authentication and the inbox use the same software. This is why I raised the two proposals in https://github.com/decentralized-identity/confidential-storage/issues/152 GNAP understands this distinction between the requesting party user agent and the requesting party client.

-

At the end, we've got a couple of requirements of Verified Credentials, which are only tangentially related to Decentralized Identifiers, by virtue of the fact that DIDs might be used to identify various entities involved in those VCs. I'm not sure that these callouts to VC are helpful to this DID use case.

It's a matter of cost, as described above. There are provisioning and privacy costs on both parties to a future communication. Whether we mention VCs by name or not, they, like verified SSL certificates, shift some of these costs among the parties.

-

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/did-use-cases/pull/126#issuecomment-758137364, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YNJN75KKTE3FI4RWNLSZM7FPANCNFSM4UWS5Y4A .

[TallTed]

@agropper --

(It's hard to read either your response, or the quoted material from my comment, in the github web interface, when you've responded by email. You might take a look at your latest comment on the pull request's web page to see what I mean. You can edit that content to clean up its presentation somewhat [markup support is limited when comments are submitted via email]. It is optimal, if possible, to post complex comments and markup through the website.)

Yes. Although in many cases, we prefer same-domain identifiers to seed an interaction even if we then escalate to less privacy-preserving identifiers. Privacy by default would have all interactions bootstrap from a same-domain identifier.

Why are "same-domain identifiers" being raised now? Where do these, or domains in general, enter into this use case, as written or otherwise? More, why do you think that "privacy by default" would be enhanced by "same-domain identifiers" for all parties? I think that these would decrease inherent privacy, because there's immediately a common point of potential failure of that privacy. Not to mention that "same-domain identifiers" would make things more centralized than DIDs, even if all DIDs in the scenario shared method and/or some deeper method-specific element(s).

Yes. We could mention some NFC, ultrasound, and almost any kind of broadcast medium. The point, I believe, is that we're starting with a broadcast rather than a directed outreach. One entity advertises and another may choose to respond. We are all painfully aware of the problems with advertising and targeted advertising. The cost of processing the advertisement is borne by the recipient so it is often essential that the advertiser incur some significant cost. I would welcome concrete suggestions as to how to improve this in this particular use-case.

So, in your mind, we're not starting from the point where Alice has engaged or is engaging Samira as therapist, but from an earlier point where Samira has broadcast an advertisement of their therapeutic services and Alice wants to act on that advertisement? None of this is in the use case, as it stands. Perhaps you would re-write it to state what you're thinking?

My objection to the apparent focus on QR Codes (as opposed to other means by which Samira could communicate her DID) was misunderstood. In hopes of being clearer, I would change "she establishes a secure connection with them by having them scan a QR code using their mobile phone to pass on her DID and enable sharing messages", to something like, "To enable establishment of a secure communication channel, Samira provides an identifier on their business card, possibly as a QR Code to be scanned, or as a URL to be typed-in. Prospective patients can use this identifier to discover how and where they can initiate an encrypted communication with Samira, through which they can provide their own identifier for reciprocal communications. From this point, both sides can send encrypted messages which only the intended recipient should be able to decrypt, and the originator of which can be verified."

The use-case could use "provision" instead of "register". One or both participants takes an action specific to the other and incurs some cost and risk. Your point about "future communications" is important. Registration itself is a one-time event that is purely a cost to both participants. It brings no immediate benefit. The reason I prefer terms like register or provision is because they communicate this two-phase nature of the process that causes you to use the word "future".

"Provision" is no better than "register", possibly even more problematic. "Provision" implies some allocation of resources for future use, which I don't think is implied by the existing "register", which at least could be taken to mean the basics of "make note of details required for use in future (secure) interaction", which I think is all that's happening. "Register" will imply to many the use of an external service, or at least the requirement of some software tool, for the recording of those details; to my mind, neither of these is required.

The "registration" you've described here doesn't cost Samira, only Alice, so I don't understand how you can now call it "a one-time event that is purely a cost to both participants."

I do not think that this, possibly any, use case need be so concerned with ancillary costs or risks, unless there would be substantial lowering or elimination of these by the solution being proposed to solve the use case. In that case, I think it better to speak of those costs and risks directly, rather than leaving them for the reader to hopefully understand through subtext as part of VCs, verified SSL certificates, or other elements of the scenario. For certain, suggesting there's much if any "cost and risk" incurred by the most minimal action in this new sphere of operation is not going to encourage participation by those who perceive little to zero "cost and risk" in their current options.

Authentication and registration does not require a service endpoint. did:key can work perfectly well for authentication and mutual authentication. The service or service endpoint comes into play when there's a transaction linked to the introduction of the parties. I agree that we should not dictate nor even suggest that authentication and the inbox use the same software. This is why I raised the two proposals in decentralized-identity/confidential-storage#152 GNAP understands this distinction between the requesting party user agent and the requesting party client.

You said there was a service endpoint for authentication. "Alice registers a service endpoint that can be used for authenticating her and an inbox for messages."

I now gather that you meant Alice was registering two things (the service endpoint, and the inbox), so there was a missing but very important comma, to wit "Alice registers a service endpoint that can be used for authenticating her , and an inbox for messages." (This would be even clearer as "Alice registers (1) a service endpoint that can be used for authenticating her and (2) an inbox for messages.")

But now you say that this service endpoint was not needed for authentication. So why is it mentioned, and explicitly "for authenticating"?

As for decentralized-identity/confidential-storage#152, that's in a repo belonging to the Decentralized Identity Foundation, and completely disconnected from this or any other DID Use Case. Also, nothing in this use case, as written, talks about either the "requesting party user agent" or the "requesting party client" -- and so far as I can tell, neither of those is discussed as playing a part in the registration, authentication, inboxing, or other action that is written as part of this use case.

It's a matter of cost, as described above. There are provisioning and privacy costs on both parties to a future communication. Whether we mention VCs by name or not, they, like verified SSL certificates, shift some of these costs among the parties.

Using VCs does not require, and is not substantially enhanced in itself by, use of DIDs. Verified SSL certificates are a cost that is removed, or at least lessened, but those were not mentioned in the None of this fits, especially as a few throw-away lines at the end, in a use case which is meant to demonstrate the need for the creation and specification of DIDs.

As noted by @jandrieu in https://github.com/w3c/did-use-cases/pull/132#issuecomment-748284949 --

This use case document is intended to illustrate real-world problems that can be solved if/when DIDs are fully realized.

With the smallest changes I can make --

Portable Secure Interactions

Samira works as a therapist. Messages between Samira and her clients are secured via mutual authentication. When she meets a new client, Samira enables a secure communications channel with them by providing her identifier, and requesting theirs. These identifiers allow both Samira and her clients to discover service endpoints that can be used to authenticate the identity of the sender of a message and to serve as an inbox for those messages. Through this connection, Samira and her clients are able to have private and confidential communications with each other at any time, over any convenient communication channel (e.g., email, chat, SMS, sneakernet, BlueTooth, and others). Because the security in all channels is based on the same identifiers, and not provided by the transport, the participants achieve the same privacy and security guarantees across all channels, and the context of their interaction likewise encompasses all the channels together. The security is portable rather than siloed, and it cannot be centralized or governed by a vendor to achieve lock-in. Clients are able to have confidence that they’re talking to Samira, and Samira is able to tell whether she is speaking to a client, or, if permitted by the client, communicating with their spouse or children. Using the same secure identifiers, clients can use different protocols to sign and send forms such as medical releases. Samira can share credentials with her clients to prove she has a valid license or board certification. Depending on the client's preference, Samira might need to share her board certification before the client grants access to their inbox. Conversely, Samira might ask a prospective client for proof of insurance before exposing her inbox to the client.

BUT I still do not see what is unique about this writeup vs existing use cases. So I ask you -- what is the new thing, unique to this use case, which is solved by DIDs, uniquely or at least superlatively vs existing solutions?

[dhh1128]

@TallTed said:

BUT I still do not see what is unique about this writeup vs existing use cases. So I ask you -- what is the new thing, unique to this use case, which is solved by DIDs, uniquely or at least superlatively vs existing solutions?

The answer is that this part of the framing is only possible because of the self-control property of DIDs (no existing mechanism can offer the feature):

Through this connection, Samira and her clients are able to have private and confidential communications with each other at any time, over any convenient communication channel (e.g., email, chat, SMS, sneakernet, BlueTooth, and others). Because the security in all channels is based on the same identifiers, and not provided by the transport, the participants achieve the same privacy and security guarantees across all channels, and the context of their interaction likewise encompasses all the channels together. The security is portable rather than siloed, and it cannot be centralized or governed by a vendor to achieve lock-in.

[TallTed]

Sorry, @dhh1128, I mis-wrote my last request.

It's not "what do DIDs bring that's new and special?" that we need, but "what does this use case bring that's new and special, relative to the other use cases in the document?"

[dhh1128]

It's not "what do DIDs bring that's new and special?" that we need, but "what does this use case bring that's new and special, relative to the other use cases in the document?"

And that brings us back to the central tension of this conversation. What I'm asking for here is a use case that contemplates the need to cross context boundaries to break out of siloed channels controlled by centralized providers (email vs SMS vs sneakernet; protocol 1 vs. protocol 2). I'm claiming that DIDs are unique in their ability to apply their security to more than one use, and that that property is so important that it justifies inventing DIDs all on its own. But as long as we constrain the definition of "use case" to only one use, the property I'm trying to highlight doesn't emerge.

[TallTed]

@dhh1128 -- OK, so you want someone to write a story (can you not write this story, since you know what you want it to say?) about the entities (humans, in this scenario, I believe) on two ends of a communications stream who (1) initiate that stream by trading identifiers, (2) initiate use of that stream with IM or email or video conference or ..., and (3) (4) (5) (etc) shift to subsequent uses of that stream among different channels (potentially including but not limited to IM or email or video conference or ...), switching between them "at will", without changing credentials and while preserving security, privacy, etc.

I see you highlighting a small difference between this and some of the existing use cases (which have been enumerated previously in this thread) -- that being the shifting of communications from one channel to another to another to another. It seems to me that this could be added to one of those existing use cases, with a (few) sentence(s).

If you agree with this assessment, perhaps you could offer a draft of such additional sentences and/or minor edits to existing sentences in an existing use case?

Or, if you continue not to see the similarity with existing use cases, a full draft of your desired story?

[dhh1128]

@TallTed : I was happy with the verbiage that Adrian proposed. That's why I quoted it back to you when you asked what was different. The ability to use the same thing in multiple contexts may be expressible in a few sentences, but it radically changes the understanding of the value that DIDs bring. Adding it to existing use cases tends to hide or de-emphasize the importance of this characteristic, since each existing use case is focused on a single use. (Noting that DIDs allow login [use case 1], and then, in a separate part of the document, noting that DIDs allow secure messaging [use case 2] misses the exciting point for me, which is doing login and secure messaging with the same identity and security, which are chosen by the DID controller rather than the channel owner. I thought Adrian's verbiage pointed that out.

But it sounds like that's not working for you. Would it help you to like this more if we changed Adrian's version from:

Samira and her clients are able to have private and confidential communications with each other at any time, over any convenient communication channel (e.g., email, chat, SMS, sneakernet, BlueTooth, and others).

...to something that is less about what's possible, and more about concrete events in the narrative? Something like:

Samira and her clients normally use email to have private and confidential communications with each other, with security rooted in their DID keys. However, sometimes they find email inconvenient. In those situations, they switch to SMS or a chat app like iChat, WhatsApp, or Slack; which one they choose depends on which is convenient for both of them, and is not the same for all of Samira's clients. Regardless, Samira and her clients are still able to use the same security as they chat; the identities of the two parties are transferrable to this new context, and the security guarantees remain unchanged. What's more, the conversations transfer seamlessly between email and chat, since what's been said is tied to the identities of the parties, not to the subset of their interactions that used a particular channel. Occasionally Samira and her clients exchange case notes, billing records, and similar data on flash drives, too; the identities, security guarantees, and cumulative context can span sneakernet as well.

This portability also manifests when the type of interaction changes from simple messaging to more structured activities. When Samira sends a bill, her clients log in to the payment website using their DIDs and keys, and complete a payment workflow in that context; there is no need to create a username and security separate from their email/chat identity. The informal chats, emails, and data files they've previously exchanged in other channels are displayed as context for the payment on the website: "Hey, it looks like you still haven't given us your copay", sent as a message last Thursday over Slack, shows up as the last activity for the client as they browse -- and the payment workflow completed on the website is interleaved with email and chat histories back in those channels.

Is that the sort of thing you are after?

[philarcher]

Thanks everyone for discussing this so thoroughly. I've amended the text a little as below to remove the trademark names of existing services and the term "sneakernet" that required the help of Messrs Page and Brin to find out what that is ;-)

We also need to specify which requirements this entails. With all that in mind, how's this:

Samira and her clients normally use email to have private and confidential communications with each other, with security rooted in their DID keys. However, sometimes they find email inconvenient. In those situations, they switch to SMS or a chat app that offers end to end encryption. The specific chat app they choose depends on which is convenient for both of them, and is not the same for all of Samira's clients. Regardless, Samira and her clients are still able to use the same security as they chat; the identities of the two parties are transferrable to this new context, and the security guarantees remain unchanged. What's more, the conversations transfer seamlessly between email and chat, since what's been said is tied to the identities of the parties, not to the subset of their interactions that used a particular channel. Occasionally Samira and her clients exchange case notes, billing records, and similar data on flash drives, too; the identities, security guarantees, and cumulative context can span physical media as well.

This portability also manifests when the type of interaction changes from simple messaging to more structured activities. When Samira sends a bill, her clients log in to the payment website using their DIDs and keys, and complete a payment workflow in that context; there is no need to create a username and security separate from their email/chat identity. The informal chats, emails, and data files they've previously exchanged in other channels are displayed as context for the payment on the website that can aggregate messages from all channels. In this way, the payment workflow completed on the website is interleaved with email and chat histories in all the channels used.

Requirements:

• Associated Cryptographic material
• No vendor lock-in
• Cryptographic authentication and communication
• Human-centered interoperability

(please see the list at https://w3c.github.io/did-use-cases/#requirements and check I’ve not missed any. If there is a new requirement arising from this, we’ll need:

• description (e.g. "Human-centered interoperability", "Decentralized identifiers need to be easy to use by people with no technical expertise or specialist knowledge.")
• Which of the benefits in the grid at https://w3c.github.io/did-use-cases/#featureBenefitGrid are relevant to this req. From my POV, it looks like ease of use and privacy.

Thanks!

[TallTed]

This is feeling a lot like "DIDs require Solid"... and while I agree that they each improve the other, I don't think that the "communications history flows from tool to tool, format to format, etc." element is (nor should be) key to DIDs.

[TallTed]

Following on my last comment, as well as those from @philarcher and @dhh1128 --

How do DIDs enable SMS to move to email, and email to move to a web forum, and web forum posts to move to SMS?

These seem entirely external to DIDs, and this "use case" doesn't feel at all like it's about DIDs, though DIDs might be used there ... Even within Solid, these wish-list items remain just that -- especially where they're shifting from communications channel to channel.

Solid attaches storage to me, not to the tool I'm using -- so all my IMs and emails and calendar items and such get written to my storage bin (not to Farceborg's or Gargle's or whomever's giant storage and mining operation in the sky) -- but it says nothing (yet?) about blending all of those things into one stream. Current expectation is that IMs are IMs and emails are emails -- so I'll use the IM tool I prefer for those, and the email tool I prefer for those -- and be able to change tools at any time without losing the content...

But again, NOTHING says that an email tool needs to know how to handle IMs nor vice versa.

[philarcher]

Thanks again @TallTed and everyone who has contributed here.

From my POV, I'm looking for consensus - and not finding it. There have been several attempts in this thread to craft a use case that covers the issue. They have been commented upon and reflected back, only to be further commented upon and edited. All that shows a lot of interest, time and commitment from several people. Again, thank you.

It's not for me or @jandrieu to dictate what does and doesn't go into the document - we're merely the people holding the pen. Translation: if this thread ends up with strong consensus that a given text should go into the doc, then, OK, it goes in. Key questions:

1. Is there a form of words that describes a human-centered use case that entails secure messaging in a way that adds a new requirement or significantly enhances an existing one?
2. Is that form of words one that everyone taking an interest here can support with no major objections?
3. If no new text is added, is the normative work of the WG affected?

Bear in mind that the Core spec is rapidly approaching Candidate Rec and, from my POV, it makes little sense to be working on a UCR when the spec itself is effectively done and ready for implementation experience. The UCR is not there to lay out the needs of the whole of the DID/VC ecosystem, just the aspects covered in the W3C core spec.

Furthermore, if the WG's current charter is completed and a new group formed to handle further aspects, another UCR or, conceivably, a new iteration of the current one, can be written. Whatever we publish as 'the final version' is actually just a snapshot.

[jandrieu]

After talking with Phil, today, we'd like to propose this adjustment, which cleans up the use of "identities"

Samira and her clients normally use email to have private and confidential communications with each other, with security rooted in their DID keys. However, sometimes they find email inconvenient. In those situations, they switch to SMS or a chat app that offers end-to-end encryption. The specific chat app they choose depends on whatever is convenient for both of them; it varies for Samira's different clients. With DIDs, Samira and her clients are able to use the same security when they chat; the identifiers of the two parties are transferable to this new context, and the security guarantees remain unchanged. What's more, the conversations transfer seamlessly between email and chat, since what's been said is tied to the identifiers of the parties, not to the subset of their interactions used in a particular channel. Samira and her clients exchange case notes, billing records, and similar data on flash drives, too; the identifiers, security guarantees, and cumulative context can span physical media.

Let's propose this as a PR.

If you have principled objections to including this to wrap up this use case discussion, speak now or forever hold your peace.

[agropper]

+1 what @jandrieu just proposed.

On Fri, Jan 22, 2021 at 11:22 AM Joe Andrieu notifications@github.com wrote:

After talking with Phil, today, we'd like to propose this adjustment, which cleans up the use of "identities"

Samira and her clients normally use email to have private and confidential communications with each other, with security rooted in their DID keys. However, sometimes they find email inconvenient. In those situations, they switch to SMS or a chat app that offers end-to-end encryption. The specific chat app they choose depends on whatever is convenient for both of them; it varies for Samira's different clients. With DIDs, Samira and her clients are able to use the same security when they chat; the identifiers of the two parties are transferable to this new context, and the security guarantees remain unchanged. What's more, the conversations transfer seamlessly between email and chat, since what's been said is tied to the identifiers of the parties, not to the subset of their interactions used in a particular channel. Samira and her clients exchange case notes, billing records, and similar data on flash drives, too; the identifiers, security guarantees, and cumulative context can span physical media.

Let's propose this as a PR.

If you have principled objections to including this to wrap up this use case discussion, speak now or forever hold your peace.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/did-use-cases/pull/126#issuecomment-765524956, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YJU4DX54TEHIOH2NFTS3GQ4VANCNFSM4UWS5Y4A .

[TallTed]

(I knew I was taking too long to type...)

tl;dr: This scenario still feels like a wish-list for future services, which is not dependent on, nor substantially changed by, DIDs. Everything I see here to which a DID is applied can be (and/or is already) equally or better satisfied by an existing CID. This doesn't mean DIDs are valueless, nor that they cannot be used for the described scenario -- just that I don't see it as a special case that needs its own use case in this document.

---

Again, I do not see how DIDs are a vital element in the following, nor how anything [1] other than much-bigger-than-current-wish-list Solid, with or without DIDs, provides this, which seems to be one of, if not the main, basis for the desire to add this use case --

What's more, the conversations transfer seamlessly between email and chat, since what's been said is tied to the identifiers of the parties, not to the subset of their interactions used in a particular channel.

I know there are ways to secure RFC 821 (SMTP) email (e.g., PGP, GPG, S/MIME), though none are really in common use. In dealing with three different banks this week, I have been forced into using three different secure "email" tools which, so far as I can tell, are really just "secure" HTML-browser-based interfaces on each bank's chosen third-party-proprietary RFC 822-ish message server. The messages are not really in my inbox; I only receive RFC821/822-based notifications of the messages on their server.

I don't know of any secure chat service (maybe Jabber has secure options?) that allows for user-preferred client tools, only proprietary chat mechanisms that force use of their own client tools, which may use TLS or similar to secure messages going from their client tools to their servers and/or directly between client tools. I know of none such that allow user authentication outside their own user registration systems.

And I certainly know of nothing that allows for shifting from (open or proprietary) chat logs (which may be on my machine or on a proprietary service provider's machine) to/from (open or proprietary) email mailboxes (which may be on my machine or on a service provider's machine) to/from other (open or proprietary) comms (which may be on my machine or on a service provider's machine), that retains messaging history from the previous mechanisms.

[1] The one system/tool I know of that comes anywhere near the above is OpenLink Data Spaces which offers some ways to intertwingle chat data with email data with calendar data, etc., and we expect to add DID support to the long list of identification and authentication methods supported by VAL, the Virtuoso Authentication Layer, but this does not directly include exposing email-as-chat nor chat-as-email (etc.), so does not directly allow choice-of-client-app nor migration-of-mechanism in anything approaching all user situations. Accomplishing the bulk of the mechanism-switching requires the users work through ODS, which must be initially set up to serve as a proxy/gateway to (i.e., client of) all the other services, which must be servers of an open spec/standard supported by ODS/Virtuoso (as client/consumer) -- and the users must likewise choose tools that speak an open spec/standard supported by ODS/Virtuoso (as server/provider). (The user's client tools need not necessarily speak the same spec as the upstream service(s); this is one of the benefits of putting ODS in play here.) But ODS and Virtuoso do all this now without DIDs in play at all, so I'm still struggling with the need for and DID-relevant uniqueness of this use case.

[creatornader]

Hi all. Thanks for engaging with this PR and sharing your different perspectives. I have taken some of the feedback and written a new PR to try to capture some of the worthwhile discussion happening here and tell the story in a clear way.

Don't mean to derail the discussion at all, but as we haven't quite reached consensus, perhaps this is something we can move forward with. Thanks.

137