Issuer identity keys lifecycle

[PaulBernier]

First I'd like to make you aware that a new generic standard for identities on Factom is being developed by Factom Inc. and we should probably migrate to that, simply because it doesn't come with all the extra un necessary stuff for our purpose (bitcoin address, m-hashes etc). As it's not yet public I won't comment more on that, just something to be aware of.

In the current spec there is no detail on the lifecycle of the identity keys. SK1 keys can be revoked and replaced. The spec should mention the time at which the SK1 should be valid (typically at the block the issuance entry is at). The new identity spec will have a method 'identity-keys-a-tblock-height" that will help do exactly that. PR #11 is changing a lot of things (and it touch idSignature) so I can make a PR to add this after it is merged, if we agree on the point I brought up.

[AdamSLevy]

How can we migrate to the new identity standard ahead of it being released? How do you suggest we manage that.

Yes we definitely need to specify which key under the identity and when it is valid for like you mentioned.

I'm hoping the PR can be merged tonight or tomorrow.

On Thu, Sep 20, 2018, 4:59 PM Paul Bernier notifications@github.com wrote:

First you should be aware that a new generic standard for identities on Factom is being developed by Factom Inc. and we should probably migrate to that, simply because it doesn't come with all the extra un necessary stuff for our purpose (bitcoin address, m-hashes etc). As it's not yet public I won't comment more on that, just something to be aware of.

In the current spec there is no detail on the lifecycle of the identity keys. SK1 keys can be revoked and replaced. The spec should mention the time at which the SK1 should be valid (typically at the block the issuance entry is at). The new identity spec will have a method 'identity-keys-a-tblock-height" that will help do exactly that. PR #11 https://github.com/DBGrow/FAT/pull/11 is changing a lot of things (and it touch idSignature) so I can make a PR to add this after it is merged, if we agree on the point I brought up.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/DBGrow/FAT/issues/14, or mute the thread https://github.com/notifications/unsubscribe-auth/AF2XcK_GR7X83E31mHAj5D2pLhRmflMGks5udDnXgaJpZM4WzSA5 .

[PaulBernier]

To be fair, I don't think that migrating the spec to the new identity scheme will be too much rework. It's more the actual implementation that would require some rework, because you have to call different APIs and parse different entries.

The identity scheme is pretty minimal/generic, it's a chain with N keys declared assocaited to that identity and those N keys are hierarchically ordered, same as with server identities where you have those 4 SK keys, and sk4 can sign to replace sk3, sk2, sk1, and sk3 can sign to replace sk2, sk1 etc. So one thing we should probably require is that the identity issuing a token has at least M keys associated with its identity (M >=2, otherwise with a single key it's impossible to rotate). Besides that rest will be pretty much the same, just the wording will change a bit I think (like not reference SK1 key for instance)

[drkatz]

Thanks @PaulBernier. Based on your knowledge of release timeline of the new identity spec, how proactive/preemptive do you recommend we should be about making those changes? (also link to Factom github branch if possible thanks!)

[PaulBernier]

Factom Inc document on identities: https://docs.google.com/document/d/1NooBhYdRARwmfqMS0lrbFoXxgbB8cFrsWIl0d0kdhF8/edit?usp=sharing Implementation: https://github.com/FactomProject/factom/tree/FD-670_IdentityWalletdAPI