Porting Identifier: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 20: Line 20:
===KERI rerolled Key===
===KERI rerolled Key===
* As designed today KERI has the ability to add re-rolled keys that can be sued at any time would the old ones become unusable.
* As designed today KERI has the ability to add re-rolled keys that can be sued at any time would the old ones become unusable.
* Should a change be forecast the user would have the time to add a new key and
* Should a change be forecast the user would have the time to add a new key and select "replace ID" you will need to be ready with a new method and ID


==References==
==References==


[[Category: Identifier]]
[[Category: Identifier]]

Revision as of 00:35, 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 providers develop 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.

KERI rerolled Key

  • As designed today KERI has the ability to add re-rolled keys that can be sued at any time would the old ones become unusable.
  • Should a change be forecast the user would have the time to add a new key and select "replace ID" you will need to be ready with a new method and ID

References