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
Comments
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:
|
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)" |
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)."
The text was updated successfully, but these errors were encountered: