Porting Identifier: Difference between revisions
Jump to navigation
Jump to search
Line 13: | Line 13: | ||
==Solution== | ==Solution== | ||
* Create a way for calls to the old identity provider to return a porting message. The following are just a few ideas and could expand or contract as new information is received. | * Create a way for calls to the old identity provider to return a porting message. The following are just a few ideas and could expand or contract as new information is received. | ||
* Recommend that all identifier provider provide a docker image for the universal resolver with code on GitHub so that should they cease operation someone else could update the method to include a porting element. | |||
===Did Method Porting=== | ===Did Method Porting=== |
Revision as of 00:09, 2 February 2021
Full Title or Meme
As older Identifier Providers cease to be viable it would be great to provide a way for a user's old provider to a new provider.
Context
- The Decentralized ID has the unfortunate behavior that when a DID method stops working for any reasons, the Identifier becomes an unusable orphan.
- Any existing identifier provider might cease operation for all sort of reasons.
Goals
- Define a method that can be added to most Identifier Providers or Methods that allows the user to be ported over to a new identifier.
Problems
- In most cases the crypto that is used in the old method is no longer viable for any new identifier.
Solution
- Create a way for calls to the old identity provider to return a porting message. The following are just a few ideas and could expand or contract as new information is received.
- Recommend that all identifier provider provide a docker image for the universal resolver with code on GitHub so that should they cease operation someone else could update the method to include a porting element.
Did Method Porting
- Add a field to the did doc called "replace ID" that will be send to any RP that tried to query the did.