[proposal] Matching identifiers by alias should not depend on the provider #1215
Labels
Comments
mirceanis
added a commit
that referenced
this issue
Aug 4, 2023
…ovider fixes #1215 BREAKING CHANGE: The behavior of `DIDManager` has changed when working with `alias`. It is mostly ignoring `provider` unless it is used to create new identifiers. `AbstractDIDStore` APIs have been adapted and implementations have changed.
mirceanis
added a commit
that referenced
this issue
Aug 4, 2023
…ovider fixes #1215 BREAKING CHANGE: The behavior of `DIDManager` has changed when working with `alias`. It is mostly ignoring `provider` unless it is used to create new identifiers. `AbstractDIDStore` APIs have been adapted and implementations have changed.
5 tasks
mirceanis
added a commit
that referenced
this issue
Aug 4, 2023
…ovider fixes #1215 BREAKING CHANGE: The behavior of `DIDManager` has changed when working with `alias`. It is mostly ignoring `provider` unless it is used to create new identifiers. `AbstractDIDStore` APIs have been adapted and implementations have changed.
mirceanis
added a commit
that referenced
this issue
Aug 4, 2023
…ovider fixes #1215 BREAKING CHANGE: The behavior of `DIDManager` has changed when working with `alias`. It is mostly ignoring `provider` unless it is used to create new identifiers. `AbstractDIDStore` APIs have been adapted and implementations have changed.
mirceanis
added a commit
that referenced
this issue
Aug 15, 2023
…ovider fixes #1215 BREAKING CHANGE: The behavior of `DIDManager` has changed when working with `alias`. It is mostly ignoring `provider` unless it is used to create new identifiers. `AbstractDIDStore` APIs have been adapted and implementations have changed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are a few methods that use or can use a combination of
aliasandproviderwhen filtering DIDs:didManagerGetdidManagerGetOrCreatedidManagerGetByAliasAbstractDIDStore.getDIDThe assumptions that lead to this design no longer hold true and
aliasshould behave uniformly, no matter theproviderused.Describe the solution you'd like
These methods should not require a
providerwhen querying.didManagerCreateanddidManagerImportusing an alias that already exists should fail, no matter theproviderused.didManagerGetOrCreateusing analiasshould fail if the requestedprovideris different than the provider of an existing identifier matching the alias.Additional context
The changes would also involve
@veramo/data-storeand@veramo/data-store-jsonThis would be a BREAKING CHANGE, since the interface definitions would be different at least for the DID stores and the behavior of some the DIDManager methods as well.
The text was updated successfully, but these errors were encountered: