The context
Building on top of boruta authorization server and wanting it to provide Self-Sovereign Identity abilities, I came to think about verifiable credential revocation. The first entrypoint on the subject was the Token status list RFC draft explaining how to manage large amount of statuses. Those are compressed to improve performance and storage needs. Having a closer look to the SD-JWT case, I came to the idea that avoiding issuer status storage would help not to mannage blacklists or whitelists but, with the usage of cryptography, to enable decentralization by including the expiration and the status information within the disclosures.
SD-JWT are verifiable credentials decribed by the IETF as JWTs provided with disclosures. They are made to share identity information in order to be able to present each piece of information apart, selecting them in the verifiable credential emitted by the issuer.
SD-JWTs contain disclosure digests that help to present and verify information in a non-disclosable way.
(1) BASE64(HMAC(<disclosure>))
The disclosures are provided along with the JWT providing the identity information and their associated salt to ensure disclosability.
(2) BASE64([<salt>, <name>, <value>])
Holding this kind of verifiable credential, you need the sided disclosures to apply the selective disclosure. It helps to get information from it by verifying the digest contained in the associated JWT. The process ensures the information provided by the holder is originated from the actual issuer of the identity traits. Here the suggested algorithm is applied to the salt in order to bring validity and status information in a decentralized way.
The rotative key idea
The essential point of credential revocation is to store validity and status information in order to be able for the issuer to check a credential status when the holder is presenting the identity information. First thinking about validity, the notion of expiration is at the heart of the TOTP algorithm providing a way to craft an opaque token that contains the expiration information and can be checked later on. Based on unix timestamp derivation with a secret, TOTP tokens provide insights to craft tokens containing validity information. For the status, the idea of shifting the timestamps gives a way to include the status information within the token. The whole allows to store the needed information to enable revocation in a light way for all parties.
This is a way of storing those information is decentralized by storing low weighted data in the identity wallets. The issuer would check it against the current user information while verifying the validity and status of the provided identity trait.
Non-opaque disclosure salt
In order to keep validity and status information decentralized, we need to produce self-supportive tokens containing those information. Following the algorithm described in the above figure, we can create tokens that can be checked to know their validity and their status. For that, the issuer has to maintain a status list mapping the status to an integer that will be used to apply the shift component of the algorithm. SD-JWT disclosures contain a salt that has no specifications, here we can make it include information which will help revocation checks. It can be composed of two parts, the first is containing information crafted by the issuer which helps the computation of the HOTP contained in the second part. The computation information has to be unique with a random part, but also need to contain the HOTP algorithm components, the time to live and the shifts. To check those contentful salts, ones need to have the issuer secret and extract the needed information from the first part to compute HOTPs for each status until match, highlighting the disclosure status, no match meaning that the disclosure is invalid or expired.
properties
- Self-suportive salt
- This way of storing revocation information is decentralized empowering low weighted data storage by the wallets.
- Tiny status list maintenance for the issuer
- The issuer has to maintain the status list. This table is tiny but important. It is important to know the status at any point of time, this may be standarized for interoperability.
- Only the issuer can check the status
- The secret componant of the HOTP algorithm helps to ensure only the issuer can verify the status information.
- Unique salt by disclosure
- The unicity of each salt helps to ensure detaining salts is not a leak for the issuer.
- Disclosure salt is required to check the validity and the status
- To check disclosure validity and status, the issuer requires the disclosure salt. It is an important constraint for the checking protocol to be used.
- Human readable ttl contained in salt
- Disclosure owners have the time to live information, it may be a hint to know the importance of the disclosure. Salts have to be kept private.
- Per disclosure validity and status information
- The granularity of this way of thinking revocation helps to think validity as per disclosure.
- Status storage scales with the number of holders
- Contrary to the actual algorithms, the validity and status information storage scales with the number of holders, not against the number of verifiable credentials.
Limits
- The interfaces to check the validity is still not standarized
- Disclosure salts has to be kept private
- Knowing the time to live of a salt can give hints about the disclosure.
- Disclosure salts weight ~30B
- The weight of a single salte is about 30B, this is compensated by the decentralized storage, the issuer does not need to store it.
- Only the issuer can check status
- The issuer has to expose a standarized endpoint to verify the disclosure
- Is it too fine grained?
- Having a per disclosure validity and status information may be too fine grained for some use cases.
Under R&D
Those works are implemented in the boruta authorization server. But still it is R&D and may need further work to be production ready. Do not hesitate to reach out if you think this can be the basis for further work or if you find this interesting, a lot of work is still to be done to find the best way to see revocation.
With care
boruta is an open-source Identity and Access Management solution implementing Self-Sovereign Identity concepts. The source code is available on GitHub.