Secure Data Storage and (DID) Wallets - Can SDS do that?

[agropper]

Wallet appears once outside of the Ecosystem Diagram and DID does not appear at all outside of the appendix. Which prompts me to open this discussion of the relationship between storage and DID wallets.

Let's start by stipulating that Microsoft Authenticator, some version of uPort, and a future release of Apple Wallet will allow anyone to choose a method and add an (info)card associated with a DID to their wallet. For a discussion of what that might look like see the superb SIOP review.

Next, allow me to scope this issue according to the major secure data storage services I now use:

• Dropbox
• GitHub
• Google Drive ($)
• Apple iCloud ($)
• email ($)
• home NAS ($) I'm not counting Twitter, and other social media because they are not secure and not counting my many web hosting providers because I don't really use any of them as storage. I pay them to answer support requests. I pay a bit of $ to all except Dropbox and GitHub. YMMV.

I use dozens of apps every day. Each one is primarily bound to one of the 6 secure data storage services above. Firefox is the only app that is bound to more than one of the secure data storage services. One independent password app has keys for all six storage services along with 200 other services. My Microsoft Authenticator and Apple Wallet has no keys for any of the six or the other 200. Almost all of the 200 services also have secure data storage of data about me but out of my control Will DIDs in my wallets change any of that?

What's missing, from my perspective, is a way to cause as many of the 200 services in my password app to use one or another of the six storage services that I control and am happy to pay for.

The standard I'm hoping for will drive these 200 vendors to keep me as a customer by offering an API to either a wallet or an agent that I control instead of them. Can SDS do that?

[agropper]

Please help me understand SDS in terms of DIDs.

There are limited ways a DID service endpoint might relate to a SDS:

• (none) Authentication Only (did:key has no service endpoints but could be a nice way to secure some services that also use storage)
• (Mediator) DID documents that use only one shared service endpoint as a proxy to avoid correlation
• (AS - Authorization Server) DID documents that point directly to a policy decision point
• (SDS - Secure Data Store) DID documents that point directly to a policy enforcement point
• (Notification) DID documents that point to a means to send a message to the DID controller

Seems to me, that all of the 200+ apps that I described to launch this issue will fall into one or another of these five service endpoint types. Also, any mature wallet tech will support DIDs across anywise, peer, and key methods.

Can we use the five service endpoint types to define the essential SDS layers? Any app developer offering DID support would pick a service endpoint type that fits their use-case. Any SDS service would advertise which of the five service endpoint types they support.

Some apps will choose and pay for their SDS and others will allow the DID controller to choose and pay for the SDS independently of the app. An app might use a DID for authentication and notification while letting the AS decide where the SDS is on a transaction-by-transaction basis.

[agropper]

Continuing after auditing more discussions of layers, profiles, and definitions, two suggestions...

Any given service, application, or actor that accepts a DID as input, could assert which of the 5 service endpoints it supports (based on standards and interop testing) with the expectation on the part of consumers that any DID with that service endpoint type would be interoperable. For example, my phone asserts compatibility with WiFi, Bluetooth, and GSM but not CDMA. If we focused on standardizing 5 specific service endpoints to start, it would not restrict adding proprietary or standard service endpoints in the future. It would merely help adoption in the short run by being clear which DIDs work with which services.

A second insight might resolve confusion around wallet vs. agent vs. storage if we can define them so there is no overlap as follows:

• a wallet has biometric UI, is capable of non-repudiable signature, does not run code plugins, and is often off-line
• an agent is expected to be on-line, runs pluggable code as a policy decision point, has lower-value private keys, and does not have storage other than for policies
• storage has general purpose storage (wallets and agents don't) and acts as a policy enforcement point relative to wallets and agents.

[dhh1128]

I just wanted to chime in to say that I largely agree with Adrian's finally bullet points. My only dissonance is that I think agents could also be offline at times. The party who communicates with one will send it a message, and won't be able to tell whether it's online when the message is dropped off at the service endpoint. That's because the service endpoint is not like a RESTful API that promises responses; it's more like a mailbox that promises sooner or later the right party will see it.

A particular subcategory of agent -- the kind that runs on a server, either on-prem or in a cloud somewhere, probably WILL be online all the time. But agents as a general category aren't guaranteed to have that characteristic.

[agropper]

@dhh1128 Yes, agents can be off-line, as can storage, mediator, or notification endpoints. What does that change about the standards for the five endpoints? There are going to be many off-line use cases where we have to deal with things like revocation and other attacks.

[dhh1128]

The subtlety here is that an agent and its endpoint don't have the same online/offline status. You can deliver a message to an agent even when it's offline -- the same way you can send an email to someone who is offline. In other words, I am saying that from the outside, you can't tell the difference between a mediator and a notification endpoint. The owner of an agent can tell the difference -- but as a caller, you can't.

[agropper]

Sorry to be thick. Acknowledgement of message delivery is a key feature. I love, for example, that iOS Message adds “Delivered” to an SMS text. But I still don’t see what you propose about any of the five proposed service endpoint standards.

[agropper]

Here is a short survey from the Glossary Group: https://docs.google.com/forms/d/e/1FAIpQLSc8Z8FklORke1iPRoyo90GNWqqXkmdbgQLNvHvU-v4XvLxO0A/viewform?usp=sf_link

[agropper]

This comment links to the recently chartered IETF GNAP workgroup that is my suggested protocol for an authorization service endpoint.