Moving DIDs and pre-rotation mechanics #46
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Stephen Curran <swcurran@gmail.com>
|
Enough writing! Now to create the presentations... |
|
@brianorwhatever or @andrewwhitehead -- ready for a review. This is definitely content that is in the "draft" stage. |
brianorwhatever
previously approved these changes
Apr 15, 2024
spec/implementors_guide.md
Outdated
| service the hash of the "next key" as defined in this specification. For | ||
| example, an entity might have the "active" DID/key hosted by one Cloud | ||
| Provider, and the "next key" by another, on the theory that an attacker might | ||
| get into one environment or another or not both. |
There was a problem hiding this comment.
Suggested change
| get into one environment or another or not both. | |
| get into one environment or another but not both. |
spec/implementors_guide.md
Outdated
| 2. Locally generate a pre-rotation key hash for a new key that will soon become the "active" key. | ||
| 3. Add a [[ref: DID log]] entry that includes the items from the previous two steps, and signs the proof using an authorized key (that presumably it controls, though not required). | ||
| 1. Although the [[ref: DID log]] could be published now, probably best to hold off and publish it after adding another entry. | ||
| 4. Get a new pre-rotation from the isolated service. |
There was a problem hiding this comment.
Suggested change
| 4. Get a new pre-rotation from the isolated service. | |
| 4. Get a new pre-rotation key from the isolated service. |
spec/abstract.md
Outdated
| as moving the DIDs web location (and so the DID string itself) while retaining | ||
| the DID's history. | ||
| unique, embedded in the DID, and derived from the initial DIDDoc. The SCID | ||
| replacement DID attacks and enables [[ref: DID portability]], such as moving the DIDs |
There was a problem hiding this comment.
Suggested change
| replacement DID attacks and enables [[ref: DID portability]], such as moving the DIDs | |
| enables [[ref: DID portability]], such as moving the DIDs |
spec/implementors_guide.md
Outdated
| @@ -13,18 +13,124 @@ The Typescript implementation is currently less than 1000 lines of Typescript co | |||
|
|
|||
| ### Using Pre-Rotation Keys | |||
|
|
|||
| Best practices are that the [[ref: DID Controller]] generates the active key for the DIDDoc where it can be used for "production" purposes, and generates the "next key" in an isolated location from production | |||
| The purpose of using pre-rotation keys is to prevent the loss of control over a | |||
| DID in the face of a compromised private key used to control the DID. The cost | |||
There was a problem hiding this comment.
Suggested change
| DID in the face of a compromised private key used to control the DID. The cost | |
| DID in the face of a compromised private key used to control the DID. The tradeoff |
spec/implementors_guide.md
Outdated
| 4. Get a new pre-rotation from the isolated service. | ||
| 5. Get the full key-rotation key reference for the pre-rotation hash created for the last [[ref: DID log entry]]. | ||
| 6. Add a [[ref: DID Log]] entry that includes the items from the previous two step | ||
| 7. If they key rotated in the previous [[ref: DID log entry]] was a/the |
There was a problem hiding this comment.
Suggested change
| 7. If they key rotated in the previous [[ref: DID log entry]] was a/the | |
| 7. If they key rotated in the previous [[ref: DID log entry]] was |
spec/implementors_guide.md
Outdated
| long as: | ||
|
|
||
| - the [[ref: SCID]] stays in the same in the new DID, |
There was a problem hiding this comment.
Suggested change
| - the [[ref: SCID]] stays in the same in the new DID, | |
| - the [[ref: SCID]] stays the same in the new DID, |
spec/implementors_guide.md
Outdated
| Consider being able to replace the current identifiers we are given (email | ||
| addresses, phone numbers) with `did:tdw` DIDs. Comparable hosting platforms | ||
| might publish our DIDs for us (ideally us still hosting own private keys...). |
There was a problem hiding this comment.
Suggested change
| might publish our DIDs for us (ideally us still hosting own private keys...). | |
| might publish our DIDs for us (ideally us still in custody of our own private keys...). |
| @@ -379,6 +387,12 @@ items are defined below. | |||
| - See the section of this specification [Using Pre-Rotation | |||
| Keys](#using-pre-rotation-keys) for non-normative guidance in using | |||
| pre-rotation keys. | |||
| - `moved`: A string that is a new `did:tdw` DID string. The new `did:tdw`: | |||
| - **MUST** contain the same [[ref: SCID]]. | |||
There was a problem hiding this comment.
Do we want to limit the location of the SCID to be the same as in the original DID? I don't think so and don't see any technical reason to do that but thought its worth asking
There was a problem hiding this comment.
No — it just have to have the SCID.
Signed-off-by: Stephen Curran <swcurran@gmail.com>
|
@brianorwhatever — back to you. Cleanups to the PR done. |
brianorwhatever
previously approved these changes
Apr 16, 2024
spec/implementors_guide.md
Outdated
| ::: todo | ||
| The primary goal of pre-rotation keys is to ensure that even if an attacker | ||
| gains access to the current active key, they will not be able to take control of | ||
| the DID. This safeguard is achieved because the attacker could simply rotate to |
There was a problem hiding this comment.
Suggested change
| the DID. This safeguard is achieved because the attacker could simply rotate to | |
| the DID. This safeguard is achieved because the attacker could not simply rotate to |
spec/implementors_guide.md
Outdated
| more. | ||
|
|
||
| From time to time in that imagined future, we will may want to move our DIDs |
There was a problem hiding this comment.
Suggested change
| From time to time in that imagined future, we will may want to move our DIDs | |
| From time to time in that imagined future, we may want to move our DIDs |
spec/implementors_guide.md
Outdated
|
|
||
| From time to time in that imagined future, we will may want to move our DIDs | ||
| from one hosting service to another, just as we move from one email or cell |
There was a problem hiding this comment.
Suggested change
| from one hosting service to another, just as we move from one email or cell | |
| from one hosting service to another, just as we move from one email or mobile |
brianorwhatever
approved these changes
Apr 16, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: Stephen Curran swcurran@gmail.com