Key Roll-over - Revision history

Tomjones at 01:58, 4 June 2020

2020-06-04T01:58:21Z

← Older revision		Revision as of 01:58, 4 June 2020
Line 1:		Line 1:
	==Full Title or Meme==		==Full Title or Meme==
	Whenever user secrets, like the ~~privet~~ keys of a cryptographic key pair, need to be refreshed by policy, good user experience requires that a graceful roll-over be enabled to minimize user disruption, especially when possession of these secrets are required for ~~authenticaling~~ user access to their property.		Whenever user secrets, like the private keys of a cryptographic key pair, need to be refreshed by policy, good user experience requires that a graceful roll-over be enabled to minimize user disruption, especially when possession of these secrets are required for authenticatiing user access to their property.

	==Context==		==Context==
Line 26:		Line 26:

	==References==		==References==
	* The wiki page [[		* The wiki page [[Cryptographic Secret Recovery]] deals the one use case for [[Key Roll-over]]

	[[Category:Authentication]]		[[Category:Authentication]]
	[[Category:Recovery]]		[[Category:Recovery]]

Tomjones: /* Call for full solutions */

2020-06-04T01:54:48Z

Call for full solutions

← Older revision		Revision as of 01:54, 4 June 2020
Line 24:		Line 24:

	Any others???		Any others???

	~~===Call for full solutions===~~
	These two efforts are just the beginning of DIF’s work in the area of secret retention and recovery. Any interested party is encouraged to contribute their ideas, code, and insights to this vital work. For more information about participating in this new initiative, and the DIF I&D WG in general, view its Meeting Page, read the group’s Charter, and join DIF!

	==References==		==References==

Tomjones: /* Full Title or Meme */

2020-06-04T01:53:42Z

Full Title or Meme

← Older revision		Revision as of 01:53, 4 June 2020
Line 1:		Line 1:
	==Full Title or Meme==		==Full Title or Meme==
	Whenever user secrets, like ~~prive~~ keys of a cryptographic key pair need to be refreshed by policy, good user experience requires that a graceful roll-over be enabled to minimize user disruption, especially when possession of these secrets are required for authenticaling user access to their ~~proporerty~~.		Whenever user secrets, like the privet keys of a cryptographic key pair, need to be refreshed by policy, good user experience requires that a graceful roll-over be enabled to minimize user disruption, especially when possession of these secrets are required for authenticaling user access to their property.

	==Context==		==Context==

Tomjones: /* Full Title or Meme */

2020-06-04T01:28:56Z

Full Title or Meme

← Older revision		Revision as of 01:28, 4 June 2020
Line 1:		Line 1:
	==Full Title or Meme==		==Full Title or Meme==
	Whenever user ~~secrekts~~, like prive keys of a ~~cyptographic~~ key pair need to be ~~refresshed~~ by policy, good user experience requires that a ~~gracefull~~ roll-over be enabled to minimize user disruption.		Whenever user secrets, like prive keys of a cryptographic key pair need to be refreshed by policy, good user experience requires that a graceful roll-over be enabled to minimize user disruption, especially when possession of these secrets are required for authenticaling user access to their proporerty.

	==Context==		==Context==

Tomjones: Created page with "==Full Title or Meme== Whenever user secrekts, like prive keys of a cyptographic key pair need to be refresshed by policy, good user experience requires that a gracefull roll-..."

2020-06-04T00:48:26Z

Created page with "==Full Title or Meme== Whenever user secrekts, like prive keys of a cyptographic key pair need to be refresshed by policy, good user experience requires that a gracefull roll-..."

New page

==Full Title or Meme==
Whenever user secrekts, like prive keys of a cyptographic key pair need to be refresshed by policy, good user experience requires that a gracefull roll-over be enabled to minimize user disruption.

==Context==
Any viable [[Identity Management]] architecture must address secrets or private key management used in user authentication.
*In a centralized [[Identity Management]] architecture the identifier is created by the IdP and so that IdP can handel recovery entirely within their own organization. Some do it well.
*In a decentralized [[Identity Management]] architecture individuals, organizations, and things create and manage their own cryptographic keys without reliance on a central authority or intermediary other than a pointer to the method used for resolving identifiers into public keys that can be used for authentication purposes.
*In a distributed [[Identity Management]] architecture the identifiers do not come with any built in resolution to any kind of resolver and so have full responsibility for any recovery of loss of access to identifiers.
Note that several existing systems that have addressed this problem include:
# Microsoft Bit Locker disk drive encryption
# Android Key Vault in version 9 and later.
# Key fobs used since 1980's and extending to USB U2F and Web Authentication devices.
# Slack provisioning user with a page of Two-factor authentication backup codes.

==Problems==
*When a user is in control of creating their own identifiers then they have the power to wield private keys that control DIDs, they can also lose everything connected to those DIDs if they can’t retain and secure them.
*By definition, in a decentralized identity system, there is no centralized service to provide an “I forgot my password” button.
That is the starting condition. It is certainly possible to build safeguards and recovery mechanisms into a decentralized identity system.

==Solutions==
* Recovery mechanisms can be as simple as creating a backup of a wallet that holds cryptographic keys or writing down a seed number on a piece of paper.
* Many key recovery techniques that are popular in the cryptocurrency community can also be applied to decentralized identity. Some of the better-known approaches are mnemonic seed phrases or Shamir’s Secret Sharing algorithm.
* In general solutions will take something the user knows and use that to recover control of the identifier, for example by doing a [[Key Roll-over]] or reload into a user device.

Any others???

===Call for full solutions===
These two efforts are just the beginning of DIF’s work in the area of secret retention and recovery. Any interested party is encouraged to contribute their ideas, code, and insights to this vital work. For more information about participating in this new initiative, and the DIF I&D WG in general, view its Meeting Page, read the group’s Charter, and join DIF!

==References==
* The wiki page [[

[[Category:Authentication]]
[[Category:Recovery]]