Key Attestation: Provide a compelling and aligned response to how key attestation will work in a decentralized context, and maybe add to companion guide

[andorsk]

I had a conversation with someone over Linkedin, and his primary concern was that you don't know how someone is managing their keys. While this is probably out of scope for the specification work done here, it is also a reasonable question w.r.t a "trust use case" and how this would work, specifically w.r.t the security persona.

I don't think this lands up in the specs themselves, but I do think having a solid answer to this question would address the "security" persona of the we've landed on as one of the key personas of the work done here.

I have attached some of the dialogue below:

If I lose my house keys, I can replace the lock. If I lose my decryption keys, I've lost everything forever.

And about trust decisions, I can verify cryptographic signatures, but how do I know that signing keys haves been properly handled at all times, and that only the legitimate signers had access to them?

It all comes down to key management, doesn't it? I keep trying to see if I missed something, but all I see from the SSI community is the lack of answers about key management and cybersecurity. And without these two things, SSI just doesn't work because no one can rely on signatures alone.

In my world, Alice cannot possibly transact with Bob without Trent telling her that Bob's cryptography can be relied upon. And conversely, Bob cannot possible transact with Alice without Trent telling him that Alice's cryptography can be relied upon.

Trent is a centralized attestation service, and in my view, it is strictly necessary. Without it, you don't have "zero trust", you have "blind faith". And once you recognize that centralized Trent must exist anyway, a completely different solution set arises to solve "decentralized trust": a network of centrally attested decentralized cryptographic agents.

I have yet to find any valid explanation as to how SSI can actually deliver on the cybersecurity promises it makes. Saying it is "out of scope" or "it will be solved by others" is like building on quicksand.

This could be part of the companion guide IMO. It's such a critical question for the advancement of the space, even if it's slightly adjacent, I think it needs to be reasonably addressed somewhere, with a concerted and aligned position from the decentralized trust community.

[andorsk]

My first thought here is that there is an implicit dynamic of trust that happens with key management. If you are really bad at managing your keys, nobody will trust you. The problem actually solves itself by virtue of the aligned incentive that people and orgs want to be trusted and additionally reputation networks will become more prominent probably. Manage your keys bad and nobody will trusts you ( which most people don't want). Your trust reputation declines. And for critical services (like government), trust is everything, so key management is a critical part for them. They are incentivized to manage their keys correctly (like everyone else)

I've had a conversation with someone else that was really interested in trust reputation, and we discussed how there's actually more overlap than obvious think between the trust registry work and trust reputation systems, which btw: means that we need to be cognizant of aligning future efforts of trust reputation networks with this.

For a security persona though, an implicit reputation system may not be satisfying, even if it's actually relatively similar to how the real world works. So, there are other ways you can give more "explicit" key management attestation that might be more satisfying.

You can of course, have additional context layers of attestation, (like an authority that audits your key management, or even manages them ) but, I do not believe this is not a "strict requirement". It may be required for some use cases, but the requirements for key management attestation probably changes with the impact of the service. Context really matters here.

As time moves on, maybe a common practice in a credential exchange is to attest which software is powering your key management, (i.e powered by hyperledger). As a verifier, I have a choice of not accepting software that isn't powered by a provider I trust, and that's completely reasonable (oh, you're powered by "mufu software? I don't trust that software, so I don't trust you )

I think this question however, needs to be continued to expanded out and a really thoughtful response needs to be given, as these are security professionals, and they will want every i dotted and every t crossed (rightly so). I of course, can wing a response, like the above, but that will probably not satisfy most security personas (even if for some reason, I am right )

As far as the definition of trust:

$\{c_i, c_j\} \in C$, one of the contexts the security persona is asking for is a key management context $c_{\text{key management context}}$. I.e I care about understanding the key management context of the entity I am interacting with to make my trust embedding.

[andorsk]

Quickly wanted to point out: That my first run-in with concern was around these efforts were with the security persona, which was exactly Allan's point in the ToIP meeting, that these concerns will be present and we will need to address them.

[a-fox]

IMO the straightforward answer is governance & audit processes. Similar to EU's upcoming 'trust mark' certification, I would assume that wallets/key management systems should acquire a certification of compliance with proper key management best practices. Of course, there's still the human-user factor for things like recovery codes, etc. but the line is likely drawn somewhere.

I wonder if Open Wallet Foundation should look into key management accreditation from wallet perspective?

[sankarshanmukhopadhyay]

I've had a conversation with someone else that was really interested in trust reputation, and we discussed how there's actually more overlap than obvious think between the trust registry work and trust reputation systems, which btw: means that we need to be cognizant of aligning future efforts of trust reputation networks with this.

"Reputation" is usually the aggregate result drawn through multiple unique inputs. In the case of the phrase "trust reputation" does this group foresee such inputs to reputation being recorded or, ist that more of an acknowledgement that a certain trust task is safe to undertake because the counter-party is observed to be reliable?

[sankarshanmukhopadhyay]

I wonder if Open Wallet Foundation should look into key management accreditation from wallet perspective?

This has been brought up in meetings but I am not sure if any individual or organization is actively pursuing the agenda.

[trbouma]

It's fascinating to watch, in the early days of nostr, everyone losing/exposing and burning their keys. Even the most experienced users are lousy at key management. What quickly fell into place was the nostr naming service (NIP-05) that enables you to keep your nostr handle, if you lose your keys.

After looking at nostr NIP-05, it is doing exactly what DIDs do. You have to place some trust in the the "did method" that there is sufficient key management capability, including key rotation, key recovery, etc. Which did methods facilitate the best, will be the ones that people trust, without needing to get into the specifics of key management.

So in the end, it's about which did method to rely on, not the actual key management (which is taken care of, by extension, the reputation of the did method). What seems to be adopting quickly is did:web, because people are already familiar with dns and make the assumption that if you can manage your website, the keys emanating from that site should be ok.

[talltree]

Tim, I completely agree, I'm not surprising that the Nostr community quickly figured out that losing a key would be tantamount to losing an account unless they added an abstraction. Ironically in adding a naming service they are just recreating DNS (I haven't looked at NIP-05). DIDs are the decentralized way to add that abstraction layer.

And yes, of course people (and companies like Microsoft) are starting with did:web because it just triangulates on the WebTrust X.509-based trust we have in websites today. I like to say that "did:web is the crack cocaine of DID methods" because it is easy to get hooked on but exceedingly dangerous because it actually adds TWO attack vectors to your DID: 1) DNS, 2) your webserver. True "native" DID methods avoid both of those, and autonomous (aka autonomic) DID methods like KERI are even more secure than that.

The main challenge of these new DID methods is simply that they are new and untested and they need peer review and real market hardening to build up confidence in their strength (for example, exactly what GLEIF is doing with KERI AIDs).