Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include transaction ranges in historical service identity keys #88

Open
letmaik opened this issue Jan 25, 2023 · 1 comment
Open

Include transaction ranges in historical service identity keys #88

letmaik opened this issue Jan 25, 2023 · 1 comment
Labels
enhancement New feature or request not-ready Not ready for implementation yet
Milestone

Comments

@letmaik
Copy link
Member

letmaik commented Jan 25, 2023

(Follow-up from #53)

The DID document contains the current but also historic service identity keys. A given service identity key is only valid to be used with a a certain range of transactions (sequence numbers, really). It would be better to include those ranges in some way for each key and then use them during receipt validation.

There are roughly two places where extra properties could go:

  • Inside the verification method object
  • Inside the JWK object

Given that the JWK object already supports a "use" field to determine intended use (e.g., signing, encryption), it seems natural to add another field in there and potentially register it at some point in https://www.iana.org/assignments/jose/jose.xhtml#web-key-parameters.

The other piece, validation, is a little more tricky, since SCITT currently does not expose CCF's transaction id in the receipt in a sensible way.

@ivarprudnikov ivarprudnikov added this to the 0.6.0 milestone Sep 12, 2023
@ivarprudnikov ivarprudnikov added the enhancement New feature or request label Jan 12, 2024
@ivarprudnikov ivarprudnikov changed the title Include transaction ranges in service identity keys in DID document Include transaction ranges in historical service identity keys Jan 12, 2024
@ivarprudnikov ivarprudnikov added the not-ready Not ready for implementation yet label Jan 12, 2024
@ivarprudnikov
Copy link
Member

Subject to changes in the receipt content which needs to include more information about the running enclave and the transaction

@ivarprudnikov ivarprudnikov modified the milestones: Next version, Backlog Jan 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request not-ready Not ready for implementation yet
Projects
None yet
Development

No branches or pull requests

2 participants