search

hyperledger / aries-rfcs

Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions
https://hyperledger.github.io/aries-rfcs/
Apache License 2.0
326 stars 217 forks source link

RFC 0050: Wallet Name #68

Closed mitfik closed 5 years ago

mitfik commented 5 years ago

During our call we started discussion about using different name for module which handles the keys. Seems like current name Wallet introduce a lot of confusion and it is already used by many projects and people in wider context.

Current definition[1]:

Wallet A software module, and optionally an associated hardware module, for securely storing and accessing Private Keys, Link Secrets, other sensitive cryptographic key material, and other Private Data used by an Entity. A Wallet is accessed by an Agent. In Sovrin infrastructure, Wallets implement the emerging DKMS standards for interoperable decentralized cryptographic key management.

This issue is meant to discuss options and elaborate on proper naming.

[1] https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit#heading=h.dj01ko326kf8

mitfik commented 5 years ago

There is already few proposition which I would like to comment on:

My suggestion would be to have few layers similar to the suggestion from MALodder and reuse definitions which are already there:

Overall is all about secure storage which we could call module and depends on the platform it could have above layers implemented in different ways.

dbluhm commented 5 years ago
  • secure element/secure enclave (HW backed or not place for storing securely secrets - you can not get anything out)

This is basically the Lox interface that @mikelodder7 described on the call. Based on Mike's presentation, I agree that secure enclave is an appropriate name for that layer.

  • Key chain - place where you can store and manage your pair of keys - can be unlocked with SE^ to get stuff out

Would the DID associated with each key pair (or pairs) also be stored in what you have termed the key chain? As an example of prior art, the key and DID "wallet" interfaces implemented today in Indy-SDK allow you to use the DID to look up keys and the public key (verification key, verkey) to look up the private key (signing key, sigkey) for operations that require it. This mechanism has felt fairly natural and comes with the benefit that the private key never leaves the library allowing the library to properly wipe memory etc..

Mentioned in some of the post-call rocket chat discussions was the question of where protocol state ought to be stored. To me, securely storing that state absolutely makes sense but it feels more like a grey area with current definitions of the wallet and what ought to be stored there. Many of us coming from Indy Agents have used the "non-secrets" wallet interface in the Indy-SDK which provides encrypted storage and tagging (I believe "non-secrets" was intended to mean "not-key-material" in this context rather than "not-encrypted").

mikelodder7 commented 5 years ago

I don’t like keychain unless it’s the same thing for protecting the keys to the kingdom. The enclave should be for material that should not leave, vault for everything else and wallet to describe all of this with networking. That gets you three layers. Lox is the security layer to access the wallet

dhh1128 commented 5 years ago

I second most of @mikelodder7 's comment above, although A) I am not confident about the label "vault" for everything else; and B) I think the relationship between lox and what sits below it is a layering one, but I don't think the relationship between the enclave and other stuff is a layering one.

I think this is a good issue, but I'm feeling like the resolution will take us a while, because I think we won't be able to rationalize the right name for the thing we currently call "wallet" until we can explain to ourselves how it fits into an overall data management strategy. And the latter question brings in the whole topic of DIF Hubs. We need to get some stakeholders from that mental model before we are confident we've really built a coherent and comprehensive model. Then we can know whether we're naming the-concept-formerly-known-as-wallet correctly.

mikelodder7 commented 5 years ago

What about these three: enclave, safe, vault?

dhh1128 commented 5 years ago

Let me state my previous comment a different way. I don't think our real problem here is lack of good words. Our problem is lack of a coherent mental model. Rather than propose words, I think we should be trying to get our mental model crisp. Until then, I don't think words will help us much.

TelegramSam commented 5 years ago

To help the conversation, I've assembled a list of 'things' we want to store and make use of inside an agent:

Our conversation should include which of the above belongs in which container by which label. Anything I missed?

dhh1128 commented 5 years ago

The wallet RFC has just such a list. See https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0050-wallets/README.md#types-of-sovereign-data

Some things that it teases out that would be worth adding to your list include:

Guardianship work has made me aware that an agent may need to access more than one of these collections of stuff--one for the guardian, one for each dependent.

dhh1128 commented 5 years ago

After thinking about this for a few days, I am feeling like I want to be able to point to the data that an agent uses directly (its keys, secrets, and so forth) as one unit of management and portability and interop, and the data that an agent doesn't use directly (cat photos or medical data that an agent may transfer, but not require directly to start up and do its basic DIDComm functions) as a different unit of management and portability.

That still doesn't tell me what to call them. I'm just saying that I feel like data required to configure and run an agent is an important subset as distinguished from all other data.

mitfik commented 5 years ago

After thinking about this for a few days, I am feeling like I want to be able to point to the data that an agent uses directly (its keys, secrets, and so forth) as one unit of management and portability and interop, and the data that an agent doesn't use directly (cat photos or medical data that an agent may transfer, but not require directly to start up and do its basic DIDComm functions) as a different unit of management and portability.

That still doesn't tell me what to call them. I'm just saying that I feel like data required to configure and run an agent is an important subset as distinguished from all other data.

Very good point! Agent would need to have some identity, which for there will be some keys and those are needed for Agent to operate. In addition Agent would deal with tons of different things (see lists above) but this is not necessary required for agent to work properly.

If we would split those two types of data maybe it would be easier to find consensus. Basically we are talking about secure place where Agent can store its credentials so he would be able to serve all kind of services. Having that in mind can we just call it secure storage to avoid confusion with the definition of wallet or simply call it Lox and use the interface which is already propose.

kdenhartog commented 5 years ago

Adding a bit of consideration to this discussion, Since a link secret and credential data is used by multiple agents in the domain we'll likely need to be able to sync this data. However, in general these pieces of data have been regarded as secrets and haven't been accessible from the Indy Wallet to sync.

This leaves me with a few options that we should be considering in this discussion:

dhh1128 commented 5 years ago

After letting this simmer for a while, I would like to propose the following terminology:

agent managed storage or AMS: What Indy used to call a "wallet" -- the software component that has no UI but that provides an interface for managing secrets and non-secrets that are tightly bound to the functioning of an agent. My rationale for this term is that A) it means exactly what it sounds like; B) it is not overloaded or used anywhere else; C) its name further clarifies the distinction between agents and hubs (an agent can't move what's in the AMS to some remote component, because then the agent has no way to prove its identity and establish trust with that remote component. The AMS is the stuff that the agent needs to have next to it.)

I further suggest that AMS be subdivided into the enclave (the storage of secrets, managed in exactly the way that secure enclaves work in hardware) and non-secrets repo (everything that the agent needs in the AMS that's not in the enclave).

wallet: changed to align with the broader understanding: an app(lication) that manages AMS and provides a UI and other features to help its user(s) do identity-related operations.

If we accept this proposal, then I suggest we use the acronym "AMS" in library names and API names everywhere that we currently use the term "wallet".

dhh1128 commented 5 years ago

^^ @talltree @jovfer @kdenhartog @TelegramSam @mitfik @nage

swcurran commented 5 years ago

I generally like this (although perhaps "agent secure storage" should be in the running? :-) ). AMS is a good term and much better than wallet for what we're talking about.

Do you envision an AMS data being replicated between agents? For example, agents running on a person's set of devices?

Also, how do you think this relates to hardware enclaves, particularly on mobile devices? How do those areas impact the AMS?

Those questions might be answered in the original storage HIPE/RFC, and if so, just point me to them. I plan to review that in the near future, but asked these questions ahead of that.

talltree commented 5 years ago

I'm open to this term but when I read the definition from @dhh1128, it wasn't at all clear to me how an AMS was different from a Hub. Daniel, can you opine a little further on that?

dhh1128 commented 5 years ago

@swcurran I assume you're laughing about "agent secure storage" because of the acronym? ;-) It wouldn't be bad if it weren't for that...

I think AMS data needs to be selectively replicated, but should NOT be blindly or fully replicated. This is one of the key differences between AMS and a normal hub--the fact that some aspects of what an AMS stores (private keys) are deliberately NOT moved to another device. A general replication policy won't work for it. (Yes, I know that a hub allows replication policy to handle this, but read on.)

The other key difference between AMS and a hub is that a hub is designed to have its own DID. This means that there must be secure communication between the hub and its owner, and that the security of that communication is based on control of private keys held on either side. So my question is: How does an agent hold private keys on its side, if those private keys are stored in the hub? Answer: it doesn't. Agent managed storage is necessarily managed by the agent for the very purpose of enabling the agent to remote to the hub. It can't be shifted.

dhh1128 commented 5 years ago

Regarding @swcurran 's question about how AMS relates to hardware enclaves: An AMS is essentially an enclave implemented in software. It can't be wholly replaced by an enclave written in hardware, because it needs more storage capacity and flexibility about storage format than a hardware enclave does. (Most hardware enclaves are capable of storing only cryptographic keys--no credentials, no link secrets, no sensitive configuration, no proofs from other parties that embody secrets we have the responsibility to guard, no witnesses for proving against accumulators, etc. And most have a very limited storage capacity--up to a small number of megabytes.) The way we connect the two is that we use a hardware enclave, if available, to store the master key that unlocks the AMS, as described here.

dhh1128 commented 5 years ago

Also, an AMS differs from a hardware enclave in that it explicitly supports an export() and import() function to make identity portable.

tplooker commented 5 years ago

I'd like to propose we separate this terminology a little different. The term KMS (key management service) is already well understood by industry, many of the large players already have products in this space and I believe it is a better fit than enclave. A KMS not only persists keys but it also exposes an API to perform cryptographic operations with the keys it persists. Enclave in my mind hints that it exposes the keys and the agent performs the associated cryptographic operations, perhaps my understanding of that term is miss-lead? Storage of encrypted data I believe is distinctly different to keys so we should have a separate term to describe that, this storage should extend to data like verifiable credentials. At the recent RWOT we coin Encrypted Data Vaults its not a term that i believe we are all 100% convince of and I could be convinced of something like Encrypted Data Storage instead, but im not sure this component needs to feature the word agent.

My summary of terms would be an agent consists of

dhh1128 commented 5 years ago

@tplooker : My understanding of the terms is a bit different. An enclave is something that holds keys and performs operations with them, without giving the private keys/secrets back across the enclave boundary. SGX is called an "enclave" in the wikipedia article on SGX; Apple's iPhones have a hardware enclave with similar properties; ARM's TrustZone is described as a "secure enclave" online. The defining characteristic of secure enclaves is that they do NOT expose the private keys, leaving it up to a caller to perform the associated operations; rather, they insist on holding the private keys themselves. exactly like the ebola photo in our "wallet" RFC depicts. A KMS is a very broad concept that includes key lifecycle management, granting and distribution, and replication; see NIST 800-130. Some KMSes implement the same key handling as enclaves, but KMSes in general allow various security policies to be defined around key management; see section 4.9.2 of the NIST doc.

We could describe a subset of the-concept-known-by-Indy-as-wallet (hereafter TCKBIAW) as a KMS. Using that term would mean our term no longer conveys the enclave semantics. Maybe that's okay, if KMS has dramatically better recognition among target audiences, or if we don't want to commit ourselves to always follow that best practice.

With respect to your second proposed term, "encrypted storage" or "encrypted data vaults" or whatever, I think you and I are talking about 2 very different things. They are both encrypted storage, but I think you're talking about something that could be provided by hubs; I am talking about something that could not, by definition. Let me give you a concrete example.

Agent X has a bunch of keys; we'll assume it stores in its KMS or enclave. Agent X has a nearby hub Y where it stores cat photos, user profiles, etc. Agent X needs a place to store the configuration that lets it access Y:

Now, the foregoing list of things can't be stored on Y, yet they do belong in encrypted storage. So where should you put them?

I claim you should put them in "agent-managed storage". They MUST be managed by the agent itself. They are not keys and therefore do not belong in a KMS.

dhh1128 commented 5 years ago

Update on this: @tplooker and @kdenhartog and I had a chat about this subject at IIW, and again at length since then. I think we reached a shared understanding. Of course, that doesn't settle this issue, as far as the community is concerned--but I thought I'd report our smaller consensus and propose it as an outcome for the larger group. Here's what we eventually agreed (after passionate debates):

  1. Although "agent-managed storage" and "AMS" are pretty accurate labels, technically, they emphasize the wrong thing. The storage-ness isn't the point; it's key-based security that's at the heart of what this component delivers. If the name of this component emphasized its role as an oracle for remembering and answering questions about keys and their associated metadata, that would be more helpful. De-emphasizing storage may also help us explain why this component does NOT overlap with hubs, and why stuffing credentials and other agent-y but not-key-related (meta)data into it may be a code smell. See this decision tree.

  2. My definition of "Key Management System" in the comment stream above may be accurate, but I was wrong to claim that many features of a KMS are out of scope for this component. The more we pondered, the more we came to believe that this component is a KMS in many ways. See this slide. This was further confirmed when we realized that many of our early design decisions about it were informed by research on "DKMS" (decentralized key management) as embodied in RFC 0051.

  3. Tobias convinced me that the thing we were calling the secrets interface in Indy wallet is just a key store, and that the DIDs and relationships necessary to use those keys intelligently are a legitimate part of the scope of a KMS that contains a key store. See this slide.

  4. Because of 1 through 3 above, I am now okay with abandoning the term "AMS" in favor of "KMS".

  5. One downside of this is that a "KMS" may set expectations higher than it should. The best technical label is probably something like "Agent Key Management Service" -- but I've reluctantly concluded that we need a shorter and more familiar label, and "KMS" is the best compromise.

  6. The relationship of the "KMS" to a secure enclave or HSM or TEE now feels clearer to me. We are expecting our "KMS" to behave like a software-implemented secure enclave, in the sense that it is opinionated about creating secrets in a safe place, and never giving them back across a boundary. See this slide and this one for very rough summaries of workflows like the ones @SmithSamuelM requested on a recent community call. The parallel is not exact, however, because we want our component to be capable of storing millions of keys, plus the DIDs and other metadata that make those keys meaningful. This suggests to me that the box labeled "key store" on this diagram could be backed by an HSM or secure enclave, but the whole KMS would not be. I also think there's still a legitimate place for the enclave wrapping technique described here -- it binds this component's data to hardware like an HSM, while offering massive scale and performance over a true HSM; its compromise is that private keys end up in ordinary RAM instead of special protected RAM for brief moments.

So: what do you think about "KMS"?

dhh1128 commented 5 years ago

@swcurran @mac-arrap @smccown ^^

swcurran commented 5 years ago

I'm happy with Key Management Service (KMS). I'm also happy with the "option 1" of the presentation slide 8 for the scope of KMS.

WRT to item 3 - I would like in the new Aries KMS implementation that the connection data be standardized and put into the key storage, rather than in the metadata (non-secrets) storage we're all currently using. All data necessary for Agent portability should be formalized and kept together.

talltree commented 5 years ago

+1 to "KMS" and +1 to @swcurran 's points. I think we might often want to character this particular type of KMS (since there are many types) as an "Agent KMS", but in most of our own usage we can just call it "KMS".

I also think it would be hugely valuable to produce a short RFC (if we don't have one already) describing the overall concept of an Agent KMS and spelling out what was decided in this thread. One key point that should be included in that is a clear set of distinctions between an Agent KMS and a Hub. I'd even boil that down to a feature table with "Yes" and "No" in the Agent KMS and Hub columns for each feature row.

mac-arrap commented 5 years ago

+1 for KMS

This aligns well with my vision of seeing the inclusion of LOXs in the future architecture.

mikelodder7 commented 5 years ago

So I've been doing lots of thinking about this. I'm happy with the naming but I want to convey a sense of how to design a secure agent KMS. I've working on this document for a while now and we should figure a way to add it as an RFC or if not an RFC, somewhere else related to this. Maybe LOX?

dhh1128 commented 5 years ago

I think Mike's doc would be good fodder for certain sections of a new RFC that documents the vision for the KMS component. Lox has enough internal complexity and sophistication that I think it justifies its own RFC, with the KMS RFC incorporating it by reference.

On Thu, Oct 24, 2019 at 11:14 AM Michael Lodder notifications@github.com wrote:

So I've been doing lots of thinking about this. I'm happy with the naming but I want to convey a sense of how to design a secure agent KMS. I've working on this document https://docs.google.com/document/d/10AXC6tRe_aqPPySeV4QzJbrteiTn5vxP9TVNSCJX2wA/edit?usp=sharing for a while now and we should figure a way to add it as an RFC or if not an RFC, somewhere else related to this. Maybe LOX?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/68?email_source=notifications&email_token=AAQ3JCBKCYVO7U3CG5Q7CI3QQHJVRA5CNFSM4HU3FIGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECFYSDA#issuecomment-546015500, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQ3JCFENKT35F5EOXVUUITQQHJVRANCNFSM4HU3FIGA .

swcurran commented 5 years ago

Are we ready for a PR that changes all appropriate references of "wallets" (as Indy currently uses it) to "KMS" in all RFCs and use that PR for community acceptance? We do need to be cognizant of where the mainstream use of the term "wallet" (https://en.wikipedia.org/wiki/Digital_wallet) is intended and don't change those instances, so it can't be a straight search-and-replace.

Per vs-code: 529 references in 42 files across the repo.

The "ams" references in the Aries SDK repo names would need to change as well.

swcurran commented 5 years ago

As I think about it - a PR across many documents to drive community agreement on KMS is a really bad approach. Too much work, and if the PR lasts a long time, it will be a merging nightmare.

Other ideas on getting community agreement? Raise it on the call and go with that?

dhh1128 commented 5 years ago

Let's raise it on a community call, with a proposal about how to implement.

I think a quick search-and-replace would work (a PR that we raise and merge in an hour after community approval on a call), IFF we could identify ahead of time the few exceptions that we don't want to alter. The other task that ought to go along with it is to open a PR for an RFC that supersedes 0050 Wallets with 0xxx KMS, that explores this component's scope, interfaces, and design carefully. That's a bigger project than the search-and-replace PR, but should be tracked as part of the same effort.

dhh1128 commented 5 years ago

@tplooker, as one of the voices who've had opinions about this in the past, can you confirm that you are on board with this approach (that my summary of our consensus is accurate)? Also, are there any other voices of strong dissent? I don't want to move ahead if there are big flaws in our consensus--but I'm feeling hopeful we're at closure.

swcurran commented 5 years ago

Let's raise it on a community call, with a proposal about how to implement.

I think a quick search-and-replace would work (a PR that we raise and merge in an hour after community approval on a call), IFF we could identify ahead of time the few exceptions that we don't want to alter. The other task that ought to go along with it is to open a PR for an RFC that supersedes 0050 Wallets with 0xxx KMS, that explores this component's scope, interfaces, and design carefully. That's a bigger project than the search-and-replace PR, but should be tracked as part of the same effort.

I don't think those should be tracked as the same effort. One is largely mechanical and gets the switch made, the other requires thought, design, collaboration and time to get right. I'm OK with a 0xxx KMS starting point that is largely mechanical, but don't recommend that we make it a blocker to making the nomenclature change.

dhh1128 commented 5 years ago

Okay. I didn't want to make it a blocker--I just wanted to launch the two pieces of work with a single community conversation so the longer task has a clear mandate. Re-reading what I wrote, I can see that what I said might have muddled that.

Let's get the change done asap.

On Thu, Oct 24, 2019 at 1:58 PM Stephen Curran notifications@github.com wrote:

Let's raise it on a community call, with a proposal about how to implement.

I think a quick search-and-replace would work (a PR that we raise and merge in an hour after community approval on a call), IFF we could identify ahead of time the few exceptions that we don't want to alter. The other task that ought to go along with it is to open a PR for an RFC that supersedes 0050 Wallets with 0xxx KMS, that explores this component's scope, interfaces, and design carefully. That's a bigger project than the search-and-replace PR, but should be tracked as part of the same effort.

I don't think those should be tracked as the same effort. One is largely mechanical and gets the switch made, the other requires thought, design, collaboration and time to get right. I'm OK with a 0xxx KMS starting point that is largely mechanical, but don't recommend that we make it a blocker to making the nomenclature change.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/68?email_source=notifications&email_token=AAQ3JCBIORXW6H3R6F2FXUDQQH457A5CNFSM4HU3FIGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECGH4BA#issuecomment-546078212, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQ3JCBXT7PVBBU4CTWVMWTQQH457ANCNFSM4HU3FIGA .

troyronda commented 5 years ago

+1 to KMS.

re slide 8 “scope”. Agree - I would refer to the concept/interface, as a whole, to be KMS (I guess option 1). (I would also think I think of “LOX” and backing storage components as both being pluggable.)

mikelodder7 commented 5 years ago

Lox to me represents the methods used to open the KMS. If you want to use federated identity for your use case, then fine but Shamirs secret sharing, OS key-rings, HSM, 3FA also work. I agree that it’s pluggable. Lox SHOULD be the best practice for opening the agent wallet. RFC0042 shows how to do it with keyrings but I should expand it for other ways.

dhh1128 commented 5 years ago

Agreed.

On Fri, Oct 25, 2019 at 11:01 AM Michael Lodder notifications@github.com wrote:

Lox to me represents the methods used to open the KMS. If you want to use federated identity for your use case, then fine but Shamirs secret sharing, OS key-rings, HSM, 3FA also work. I agree that it’s pluggable. Lox SHOULD be the best practice for opening the agent wallet. RFC0042 shows how to do it with keyrings but I should expand it for other ways.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/68?email_source=notifications&email_token=AAQ3JCDY2WW7FCELZR2QSHDQQMQ55A5CNFSM4HU3FIGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECI6M7Y#issuecomment-546432639, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQ3JCECXVJEF4N77HAYHX3QQMQ55ANCNFSM4HU3FIGA .

talltree commented 5 years ago

+1, Mike. You nailed it.

On Fri, Oct 25, 2019 at 1:32 PM Daniel Hardman notifications@github.com wrote:

Agreed.

On Fri, Oct 25, 2019 at 11:01 AM Michael Lodder notifications@github.com wrote:

Lox to me represents the methods used to open the KMS. If you want to use federated identity for your use case, then fine but Shamirs secret sharing, OS key-rings, HSM, 3FA also work. I agree that it’s pluggable. Lox SHOULD be the best practice for opening the agent wallet. RFC0042 shows how to do it with keyrings but I should expand it for other ways.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/hyperledger/aries-rfcs/issues/68?email_source=notifications&email_token=AAQ3JCDY2WW7FCELZR2QSHDQQMQ55A5CNFSM4HU3FIGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECI6M7Y#issuecomment-546432639 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAQ3JCECXVJEF4N77HAYHX3QQMQ55ANCNFSM4HU3FIGA

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/68?email_source=notifications&email_token=AAZOITL53E5XLLMWNLJE42LQQMUUPA5CNFSM4HU3FIGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECJA6FQ#issuecomment-546443030, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZOITPK2CJ5RKAUFKCYBGLQQMUUPANCNFSM4HU3FIGA .

mac-arrap commented 5 years ago

@swcurran are you proposing we rename in Indy as well? I might of misread your comment

swcurran commented 5 years ago

@mac-arrap - I don't really care about what happens in Indy as I think that part of Indy is being deprecated. As long as it is around it will continue to be a point of confusion ("it's the wallet in a wallet"), but I think trying to fix it will be more then anyone is willing to take on.

kdenhartog commented 5 years ago

Discussed on the call today: Decision made was on the call and the term "Key Management Service" will be used and an update to RFCs was updated was agreed upon.

@jadhavajay has volunteered to update RFCs with this new work.