Decide on whether we're deprecating `did:ion`

[mistermoe]

[!WARNING] hold off on implementing any additional functionality related to did:ion until a decision is made

[!NOTE] Hoping to land a decision here by EOD 11/14/2023 US

both web5-kt and web5-js have did:ion implementations. We need to decide whether we want to deprecate did:ion and when.

I imagine we'll likely want to wait until we have did:dht implemented in at least both sdks. If we intend to continue maintaining did:ion we need to produce test vectors.

[mistermoe]

cc: @csuwildcat

[mistermoe]

cc: @emilycc @michaelneale

[csuwildcat]

The did:dht method is so much simpler for SDKs, client apps, and node implementers/operators that I think this is the right call.

[mahoekst]

For now I would recommend any PFI to use did:web, if we need to implement a self-custodian scenario we can use did:jwk until we have did:dht finished (and/or did:ion depricated)

[csuwildcat]

To future proof us, I would suggest we at least use did:key (did:jwk might work, but I need to check) with Ed25519 keys, because we can basically upgrade did:key DIDs to have the capabilities of DID DHT and resolvable endpoints, while gracefully degrading back to being ordinary did:key IDs

[mahoekst]

The DIF interop profile specifies did:web did:jwk and did:ion right now. https://identity.foundation/jwt-vc-presentation-profile/ https://identity.foundation/jwt-vc-issuance-profile/ so that choice would need some work as well. (of course we can create another profile :))

[csuwildcat]

Should be able to make did:jwk work, we would just need to use Ed25519 keys. The Mainline DHT that backs BitTorrent uses Ed25519 keys for its k/v pairs, so any method that represents an Ed25519 key is theoretically in play for us to be able to gracefully upgrade from a neutered DID method to a fully fledged one.

[frankhinek]

One thing worth noting is that neither AWS nor GCP KMS support Ed25519 yet, which is relevant since we know at least some interested partners plan to use AWS KMS for secure key management.

Here are a couple of relevant issue trackers for GCP: https://issuetracker.google.com/issues/232422224 https://issuetracker.google.com/issues/231334600

Worth noting this comment from a Google representative:

Our Cloud KMS and Cloud HSM services run strictly in FIPS mode and since the EDDSA set of curves are not currently NIST approved, we are unable to support ED25519 or ED448 at the moment. However, we'll keep your request in our system and will let you know if any changes in the future.

With the addition of Ed25519 in FIPS 186-5 & NIST SP 800-186, published Feb. 3, 2023, this might prompt HSM manufacturers and the downstream hosted KMS providers like AWS and GCP to add support.

[csuwildcat]

@frankhinek but if we have PFIs and companies using did:web, they can use whatever keys they want. This is more for individuals, who don't need KMS support.

[decentralgabe]

the method is implemented in go, ts, and kotlin (after this PR).

we have a server that's deployed at diddht.tbddev.org. the server needs ongoing development, but is usable for non prod use cases today.

To @mahoekst's point -- I wouldn't take the interop profile too seriously yet. The profile is a bit stale. It's more important that we have our own profile (and our own sense of certainty) about what we're supporting.

To @frankhinek's point -- It is frustrating there's no KMS support for Ed25519. Practically, when HSMs/KMSs are required, we should recommend did:web or did:jwk as a last resort.

I am thinking jwk - mostly used for testing or ephemeral use cases dht - used for individual DIDs and organizations without HSM/KMS requirements web - organizations

[michaelneale]

what are the reasons to keep did:ion? (the theoretical discovery aspect with types right now is one) - I assume is some good ones.

[csuwildcat]

We can do discovery just as well with DID DHT, so as that comes online as our flagship, there's little reason to keep ION around.

On Thu, Nov 9, 2023, 7:53 PM Michael Neale @.***> wrote:

what are the reasons to keep did:ion? (the theoretical discovery aspect with types right now is one) - I assume is some good ones.

— Reply to this email directly, view it on GitHub https://github.com/TBD54566975/sdk-development/issues/14#issuecomment-1804953748, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABAFSX3R4DD3FZRYNC4XV3YDWCITAVCNFSM6AAAAAA7EAXSGGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBUHE2TGNZUHA . You are receiving this because you were mentioned.Message ID: @.***>

[decentralgabe]

ION is deprecated.