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

Terminology & lifecycle: revoke / rotate #161

Closed
fimbault opened this issue Jan 20, 2021 · 2 comments · Fixed by #384
Closed

Terminology & lifecycle: revoke / rotate #161

fimbault opened this issue Jan 20, 2021 · 2 comments · Fixed by #384
Assignees

Comments

@fimbault
Copy link
Collaborator

So I was starting to have a look at rotation/revocation issues (keys or tokens), as we have many open issues that relate to that

Interesting insight from DIF KERI (Universal Identifier Theory paper)
"The term revocation has two completely different meanings in the identity space. In key management one may speak of revoking keys. With statement issuance, authorization issuance, or credential issuance, one may speak of revoking an authorization statement, a token, or a credential. This becomes confusing when the act of revoking keys also implicitly revokes the authorization of statements signed with those keys."

and "KERI terminology usually avoids that confusion between rotation and revocation because a key rotation operation is the equivalent of a key revocation operation followed by a key replacement operation. So one operation, rotate, is implemented instead of two operations (revoke and replace)."

@fimbault
Copy link
Collaborator Author

fimbault commented Jan 20, 2021

Related question: what is persistent (drawback, need to store that info somewhere, safely) ? what is ephemeral ? what's the lifecycle of related objects?

And more specifically:

  • every new request needs to provide a key -> don't need long term persistance for that, we simply need to handle key rotations during a single request (as described in issue Key rotation within continuation #85)
  • objets derived from some underlying key however (including bound tokens) might be more tricky ( ex rotation of tokens related to Continuation Request? #147 ). Do we need some kind of registry to keep track of the changes over time, to keep them alive even if the key changes? Or do we just consider that they get revoked? (and what happens if you fall into that case at some point, what's your next action?)

@fimbault fimbault changed the title Terminology : revoke / rotate Terminology & lifecycle: revoke / rotate Jan 20, 2021
@fimbault fimbault self-assigned this Oct 8, 2021
@fimbault
Copy link
Collaborator Author

This is already managed by section 7.2 "If the flags field does not contain the bearer flag and the key is absent, the access token MUST be sent using the same key and proofing mechanism that the client instance used in its initial request (or its most recent rotation)"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant