Porting Identifier: Difference between revisions
Jump to navigation
Jump to search
| (15 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==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. | As older Identifier Providers cease to be viable it would be great to provide a way for a user's old provider to easily port to a new provider. | ||
==Context== | ==Context== | ||
* The [[Decentralized ID]] has the unfortunate behavior that when a DID method stops working for any reasons, the Identifier becomes an unusable orphan. | * 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. | * Any existing identifier provider might cease operation for all sort of reasons, both planned and unplanned. | ||
===Goals=== | ===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. | * 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 as the need arises. | ||
==Problems== | ==Problems== | ||
* In most cases the crypto that is used in the old method is no longer viable for any new identifier. | * In most cases the crypto that is used in the old method is no longer viable for any new identifier. | ||
* These are the known use cases that require porting: | |||
# The identifier that was given to the user at enrollement needs to be replaced by the method provider during insertion of the id into the ldeger. | |||
# The method provider determines that the method needs to be retired and helps the user to create a new identifier on a new method and insert a "replace ID" in the old did-doc. | |||
# The method suddenly become unusable and the key controller (user) has no notice of the termination. | |||
# The user loses control of the key but has the foresight to include a pre-rolled key with an oracle to initiate thee roll. | |||
==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 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. | * 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=== | ===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. | * 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 | ===KERI prerolled Key=== | ||
* As designed today KERI has the ability to add pre-rolled keys that can be used at any time should 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== | ==References== | ||
[[Category: Identifier]] | [[Category: Identifier]] | ||
Latest revision as of 01:17, 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 easily port 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, both planned and unplanned.
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 as the need arises.
Problems
- In most cases the crypto that is used in the old method is no longer viable for any new identifier.
- These are the known use cases that require porting:
- The identifier that was given to the user at enrollement needs to be replaced by the method provider during insertion of the id into the ldeger.
- The method provider determines that the method needs to be retired and helps the user to create a new identifier on a new method and insert a "replace ID" in the old did-doc.
- The method suddenly become unusable and the key controller (user) has no notice of the termination.
- The user loses control of the key but has the foresight to include a pre-rolled key with an oracle to initiate thee roll.
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 pre-rolled keys that can be used at any time should 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.