-
Notifications
You must be signed in to change notification settings - Fork 233
feat: Add Token Status List support for SDJWT VC #2326
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
base: main
Are you sure you want to change the base?
Conversation
|
Signed-off-by: DaevMithran <daevmithran1999@gmail.com>
Signed-off-by: DaevMithran <daevmithran1999@gmail.com>
Signed-off-by: DaevMithran <daevmithran1999@gmail.com>
Signed-off-by: DaevMithran <daevmithran1999@gmail.com>
Signed-off-by: DaevMithran <daevmithran1999@gmail.com>
Signed-off-by: DaevMithran <daevmithran1999@gmail.com>
Signed-off-by: DaevMithran <daevmithran1999@gmail.com>
Signed-off-by: DaevMithran <daevmithran1999@gmail.com>
Hey @TimoGlastra I think this is ready for your review if you get capacity! Would be awesome to have this added, and can be consumed directly by Paradym |
...rc/modules/sd-jwt-vc/credential-status/token-status-list/http/HttpTokenStatusListRegistry.ts
Outdated
Show resolved
Hide resolved
issuer.method === 'did' | ||
? async ({ protectedHeader: { alg, kid } }) => { | ||
if (!kid || typeof kid !== 'string') throw new CredoError('Missing kid in protected header.') | ||
|
||
const { did } = parseDid(issuer.didUrl) | ||
const didUrl = `${did}${kid}` | ||
const didsApi = agentContext.dependencyManager.resolve(DidsApi) | ||
const didDocument = await didsApi.resolveDidDocument(did) | ||
const verificationMethod = didDocument.dereferenceKey(didUrl) | ||
const publicJwk = getPublicJwkFromVerificationMethod(verificationMethod) | ||
|
||
return { | ||
alg, | ||
method: issuer.method, | ||
didUrl, | ||
jwk: publicJwk, | ||
} | ||
} | ||
: undefined, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the jwt is now signed with something else than did
we don't check if it's actually signed by the SdJwtVcIssuer.
I think we should use jwsSigner
instead and provide it beforehand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TimoGlastra Could you share some references for jwsSigner
if (uri) { | ||
if (isDid(uri)) { | ||
method = parseDid(uri).method | ||
} else if (isURL(uri)) { | ||
method = 'http' | ||
} else { | ||
throw new TokenStatusListError('Status List Uri is not supported') | ||
} | ||
} else if (issuer && issuer.method === 'did') { | ||
method = parseDid(issuer.didUrl).method | ||
} else { | ||
throw new TokenStatusListError('Status List Uri is not provided') | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding this logic here, makes the registry not really extendable by nature.
I think it would make more sense to provide an uri to the registry and match based on regex (like we do with anoncreds). Both the iss
/uri
values can be passed to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There could be multiple handlers for each uri according to regex is it?
I was thinking for all http uri's they would be consistent and followed a pattern similar to did registrar, anyone can register a custom HTTPTokenStatusListRegistry and the different DID methods it can support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TimoGlastra Made the changes
protectedHeaderOptions: { | ||
alg: issuerKey.alg, | ||
typ: header.typ, | ||
kid: issuerKey.kid, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In case the status list is signed by a did, this should be the did key reference, not the KMS key reference. Is that the case when a did is used?
packages/core/src/modules/sd-jwt-vc/credential-status/token-status-list/TokenStatusList.ts
Outdated
Show resolved
Hide resolved
packages/core/src/modules/sd-jwt-vc/credential-status/token-status-list/TokenStatusList.ts
Outdated
Show resolved
Hide resolved
packages/core/src/modules/sd-jwt-vc/credential-status/token-status-list/TokenStatusList.ts
Outdated
Show resolved
Hide resolved
* @internal | ||
*/ | ||
@injectable() | ||
export class TokenStatusListService { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking whether we should make this an external module, and not depend it on SD-jWT VC, but for now it's fine i think.
packages/core/src/modules/sd-jwt-vc/credential-status/token-status-list/TokenStatusList.ts
Outdated
Show resolved
Hide resolved
Signed-off-by: DaevMithran <daevmithran1999@gmail.com>
Signed-off-by: DaevMithran <daevmithran1999@gmail.com>
e2fbaab
to
fbeda86
Compare
This PR adds support for Token Status Lists in SD-JWT VC credentials, based on the specification ([spec link]).
Features:
The approach to configuring Token Status List registries follows the same pattern used for registrars and resolvers. This ensures flexibility and consistency within the framework.
Default Behavior:
HttpTokenStatusListRegistry
to publish and manage status lists via HTTP endpoints.Custom Registry Support:
Consumers can override the default behavior by implementing the
TokenStatusListRegistryInterface
and configuring custom registries at module startup.Example: