Porting Identifier - Revision history

Tomjones: /* KERI prerolled Key */

2021-02-02T01:17:14Z

KERI prerolled Key

← Older revision		Revision as of 01:17, 2 February 2021
Line 28:		Line 28:

	===KERI prerolled Key===		===KERI prerolled Key===
	* As designed today KERI has the ability to add pre-rolled keys that can be ~~sued~~ at any time ~~would~~ the old ones become unusable.		* 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		* 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.		* 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.

Tomjones: /* KERI prerolled Key */

2021-02-02T01:16:49Z

KERI prerolled Key

← Older revision		Revision as of 01:16, 2 February 2021
Line 28:		Line 28:

	===KERI prerolled Key===		===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.		* As designed today KERI has the ability to add pre-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.		* 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.

Tomjones: /* Context */

2021-02-02T01:15:00Z

Context

← Older revision		Revision as of 01:15, 2 February 2021
Line 4:		Line 4:
	==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===

Tomjones: /* Full Title or Meme */

2021-02-02T01:14:15Z

Full Title or Meme

← Older revision		Revision as of 01:14, 2 February 2021
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==

Tomjones: /* Goals */

2021-02-02T01:13:41Z

Goals

← Older revision		Revision as of 01:13, 2 February 2021
Line 7:		Line 7:

	===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==

Tomjones: /* Problems */

2021-02-02T01:12:33Z

Problems

← Older revision		Revision as of 01:12, 2 February 2021
Line 11:		Line 11:
	==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 ~~user~~ cases that require porting:		* 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 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 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.

Tomjones: /* Problems */

2021-02-02T01:11:59Z

Problems

← Older revision		Revision as of 01:11, 2 February 2021
Line 12:		Line 12:
	* 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 user cases that require porting:		* These are the user 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 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 method suddenly become unusable and the key controller (user) has no notice of the termination.

Tomjones: /* Problems */

2021-02-02T01:10:33Z

Problems

← Older revision		Revision as of 01:10, 2 February 2021
Line 11:		Line 11:
	==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 user cases that require porting:
			# 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.

Tomjones: /* KERI prerolled Key */

2021-02-02T01:07:32Z

KERI prerolled Key

← Older revision		Revision as of 01:07, 2 February 2021
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]]

Tomjones: /* Solution */

2021-02-02T01:05:20Z

Solution

← Older revision		Revision as of 01:05, 2 February 2021
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 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.		* 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.		* 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.