2022 10 03 Meeting Minutes

October 3, 2022

Meeting Recording

Agenda

• Reviewing the draft conceptual architecture and making live updates
• Determining next steps

Attendees

• Tracy Kuhrt, Accenture
• Andrew Hughes, Ping Identity
• Drummond Reed, Avast
• Hart Montgomery, Linux Foundation
• John Walker, Trust Registry
• Kolowole
• Lucy Yang
• Orie Steele, Transmute
• Thomas Schwarz
• Shawn Butterfield, Salesforce
• Troy Ronda, Avast
• Eu Gene Lim, Accenture

Discussion

Storage

• (Orie) One point of confusion has been the concept of using device keys to protect content that is only decryptable on the device versus storing content only on the device. (Orie)
• (Orie) Two sides to the native mobile experience
  • Content only exists on the device
  • Content exists persisted elsewhere and is only accessible on the device
• (Hart) Do we want to include key sharing or distributed key management? We may need to store key shares with a requirement on the protocols that are specific to storage rather than managing different objects.
• (Hart) Everything is a digital object -- classify digital objects by what we need to do with them rather than what they are. Think about the objects that are required for the different use cases and classify based on functionality.
• (Hart) Do you want to see MPC functionality?
• (Hart) What do we want things to do? How will we use the digital objects?
• (Hart) Ultimately all of the digital objects might just be represented with cryptographic keys.
• (Drummond) What do you mean? That all digital objects will be associated with a cryptographic key?
• (Hart) Well you could encode a hotel key as a cryptographic key. Or if credit cards were being redesigned today, they might be stored as a cryptographic secure string or a cryptographically long string.
• (Drummond) But something like a passport would not be stored as a cryptographic key.
• (Hart) That would be some kind of object, but what are you using the passport for (proving something about yourself).
• (Drummond) all of the objects need secure storage.
• (Drummond) the one thing the wallet has to be excellent at is key storage and access.
• (Thomas) What are we talking about when we talking about when we talk about key share? Two people having access to a hotel key? Shamir secret? Multisig?
• (Hart) It could be all of the above. Sharing a hotel key is easier than a Shamir secret share protocol. I was thinking specifically of Shamir secret sharing. Size of the transaction might need a protocol using a Shamir. Could be a simple MPC.
• (Tracy) Storage was intended to represent where you store the digital objects. Key shares seem like it is the actual share of the key vs. storage of the key.
• (Hart) Key share is a digital object rather than a storage location.
• (Orie) Working on confidential storage initiative at Decentralized Identity Foundation with W3C. Built a demo of wallet portability built on top of work called "encrypted data vaults". In order for that to work, there had to be key material that you could use to obtain plaintext objects. The key material had to be available on the client. It was possible to synchronize the collection of digital objects to multiple remote servers. A lot of the digital object categories that I care about is in that space. It is a file that I can choose to synchronize or replicate to as many remote storage locations as desired, but in order to obtain the plaintext digital object that I want, I would need to decrypt it. Client will have to have access to some key material, but the digital objects do not need to be limited to only be on that client.
• (Drummond) General points of consensus that we can build on for future calls.
• (Eu Gene) Client is responsible for key storage, but not digital object storage. A wallet by definition is where you bring your access cards and keys. Wallet would not just be a client using the digital objects vs. the storage. Service provider would remain knowledgeable of the keys, but the client would have access to decrypt them.
• (Eu Gene) Storage at the wallet level would store the key, we would need to figure out key management and its lifecycle. Client that stores the key is the boundary with hooks into the wallet.
• (Tracy) Summarize on Storage - all agree that there will be multiple locations where things are stored. For a given wallet, there could be multiple storage locations that could be accessed. In certain cases, only a certain device would have access to the storage.
• (Eu Gene) From a local storage perspective, should we distinguish between software vs. hardware?
• (Tracy) The architecture captures the hardware based storage under Trusted Execution Environment.
• (Orie) Content storage is a function of key storage.
• (Drummond) Key Storage - that functionality is usually referred to as a KMS. Are we talking about a standardized KMS interface for an open wallet?
• (Orie) Short answer - we might in the future talking about a façade interface between many key management systems (Azure, Amazon, GCP, HashiCorp vault). Build on one and swap out for another if we build out a single interface (hard problem, not necessarily out of scope). Need to define the abstraction and interface that will satisfy the use cases. What are the capabilities that I need for hardware-backed DID management? What are the capabilities I need for hardware-backed credential issuance? If you add up all the use cases, you might get to a generic interface into key management services where you have portability across several KMS. I do not know how much we work we intending to do here, but it does seem like it is kind of core of enabling a lot of agility and protability in the wallet ecosystem. The connection point between "how are my keys stored in a safe way and how can I be sure that I am the only one using them?" seems like a fundamental capability that seems to be enabling all of the other higher order use cases.
• (Hart) We absolutely need something like this as the fundamental core of the wallet. If we do not have secure storage, then everything else does not work. I do not think we will be able to get to a single interface. Functions for an MPC storage system will look different from a basic storage system. Not too large number of interfaces that focuses on specific storage cases. Have the ability to swap out a TEE fairly easily.
• (Eu Gene) Use cases will drive what we focus on to get to standard alignment. Having backend providers manage your keys for you with custody of keys on your behalf. Need to support self-custodial solutions vs. managed custodial solutions.

Digital Objects

• (Hart) It would be useful if we could classify digital objects based on functionality and what we expect them to do. What is a hotel key? It is fundamentally a token that lets you authenticate yourself to something. Similar for event keys (although with limits of usage).
• (Tracy) Does this mean that we look at the protocols that the digital objects use?
• (Hart) Group digital objects based on the protocol they use.
• (Lucy) For a business user, there could be some bigger category. How do we differentiate the objects?
• (Tracy) How do we divide the protocols from the digital objects? Need separation between the protocol layer and the digital object layer. The digital object layer is intended to tie together the storage and the protocol. The digital objects are what you are storing. The protocols are what you can do against those digital objects.
• (Orie) Architecture division - have seen versions of this pictures before with the policy engine as the gateway to the digital objects. Another form of architecture where the protocols are attached directly to the digital objects. This can add confusion and be dangerous. What parts make sense? A verifiable credential is an object that has some interactions that are attached to the object -- verify -- plus other actions that you can take with those credentials (clone). If the digital objects are instances of the class with methods you get a different architecture than if you think of those digital objects just as a data structure where all of those interaction points have to come from a higher order like a boundary, or the policy engine or a manager class. Depending on how you treat the digital objects they could be data structures or data structures where methods that allow you to interact with them directly. The object oriented version as leading to complicated code. Whereas a data structure that must go through a typed interface have an easier to manage.
• (Eu Gene) Protocol management aspect, instrument management aspect. For example, the transport/communication protocol is different from the business domain protocol. Instrument management would be more at the implementation level. Communication protocol should be thought of as different.
• (Tracy) Protocols as the rules that need to exist vs. communication management.

Next Steps

• View for what Hart has suggested for looking at the digital object layer in a different way -- specifically functionality based.

Question

• (Andrew) Where did we end up on the discussion between Agent and Wallet?
• (Orie) Really excited about agents. Wallets are a thing that an agent can access on your behalf. Agents are an upper portion of the stack that we can ignore for a long time as we develop the API for how humans can interact with the wallet. Maybe we have a digital object called agent that represents my preferences for how these objects are managed. Custom models as a class of digital objects that consumers will interact with in the near future.