You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This idea comes from our discussions in defining did:webvh (formerly did:tdw -- https://identity.foundation/trustdidweb/next). It would be good to have a version defined in the log that defines what version of this specification that the writer is using, and to allow a new version to be used later in the log to change the version. That enables:
Defining a tightly as needed (possible) what dependent specifications are being used in a given version of the spec -- e.g. what hash algorithms are allowed, what proof formats are allowed, and so on. This simplifies implementations and enables interoperability.
Updating the version allows the specification to evolve, and to support later dependent specifications -- such as post-quantum.
Multibase, etc. should still be used to enable multiple (for example, hash, DI) algorithms to be used in a version, but should not be used as a reason to let any writer use anything they want. That's too much of a burden on log readers.
By being able to change the version over time, the logs can be long-lasting, which we assume is a goal. In our case of DID Documents, we want them to last for many years. Being "agile" with the underlying algorithms is crucial.
The text was updated successfully, but these errors were encountered:
This idea comes from our discussions in defining
did:webvh
(formerlydid:tdw
-- https://identity.foundation/trustdidweb/next). It would be good to have aversion
defined in the log that defines what version of this specification that the writer is using, and to allow a newversion
to be used later in the log to change the version. That enables:The text was updated successfully, but these errors were encountered: