Porting Identifier: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 24: Line 24:
* 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 select "replace ID" you will need to be ready with a new method and ID
* 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
* To enable sudden loss of the provider it is recommended that the KERI method support "oracles" that can be used by the key controller (owner) to roll to a new key.


==References==
==References==


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

Revision as of 01:07, 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 "replace ID".
  • This process will be triggered when the user attempts to sign into a RP that they have used before the update.
  • In those cases the RP will call for a did-doc which will now contain the "replace ID" entry. This should all happen transparently to the user.

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.
  • This method could also be used in place of "Equivalent Key" to move the user to updates that come with the provisioning of the DID on the blockchain or other ledger.

KERI prerolled 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
  • To enable sudden loss of the provider it is recommended that the KERI method support "oracles" that can be used by the key controller (owner) to roll to a new key.

References