quartzjer
commented
1 year ago This is a design choice, there is some language regarding this in the security section of the spec.
To expand on that here, it is simply not a function of a DID URI to conform one-to-one with any given key. DID URIs are by definition abstract and separate from the one-or-more keys that are related to that DID.
Secondarily, the creator of the DID URI is responsible for encoding it, and all consumers should be preserving that string exactly as-is. Only their DID resolver is decoding it and returning a DID Document. The creator of the DID URI could decide to encode it differently in another usage, but that is always a new DID (that just happens to have the same key).
Appreciate the question, hope that helps clarify :)
davux
I love the simplicity of being able to express a key as a DID. I think this is a great bridge between the two worlds, that has a lot of use cases.
One possible issue I'm seeing is that a same key pair can lead to different DIDs, depending on variations such as the order of keys in the JWT, for example. Maybe there are additional inventive ways to come up with such variations.
I know that in normal situations this won't be a problem, because you'll usually decode the key back from the DID and check some signature related to it. However, there might be a few situations where you start from the key and can produce different DIDs depending on encoding, so non-uniqueness would become an issue.
Do we consider this could be a problem? We can just accept that characteristic and keep things simple, or we can try and add uniqueness, with the risk of making the algorithm more complex.