feat: Add Token Status List support for SDJWT VC#2326
feat: Add Token Status List support for SDJWT VC#2326DaevMithran wants to merge 19 commits intoopenwallet-foundation:mainfrom
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>
DaevMithran
changed the title
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 |
| 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.
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.
@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.
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.
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.
| protectedHeaderOptions: { | ||
| alg: issuerKey.alg, | ||
| typ: header.typ, | ||
| kid: issuerKey.kid, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
In the test, did is being used for signing. Below is an example of the statusList created.
Header
{
"alg": "EdDSA",
"typ": "statuslist+jwt",
"kid": "#key-1"
}Body
{
"status_list": {
"bits": 1,
"lst": "eNpjYAAAAAIAAQ"
},
"iss": "did:cheqd:testnet:804f2bd3-ccb7-40bf-aec1-be71e4af525e",
"iat": 1769542847
}
DID Document
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/jws-2020/v1"
],
"id": "did:cheqd:testnet:804f2bd3-ccb7-40bf-aec1-be71e4af525e",
"controller": [
"did:cheqd:testnet:804f2bd3-ccb7-40bf-aec1-be71e4af525e"
],
"verificationMethod": [
{
"id": "did:cheqd:testnet:804f2bd3-ccb7-40bf-aec1-be71e4af525e#key-1",
"type": "JsonWebKey2020",
"controller": "did:cheqd:testnet:804f2bd3-ccb7-40bf-aec1-be71e4af525e",
"publicKeyJwk": {
"crv": "Ed25519",
"kty": "OKP",
"x": "dle5ymF3KSXDnlKBvd0fB_CRjjZlRXV4yzhukuhguSU"
}
}
],
"authentication": [
"did:cheqd:testnet:804f2bd3-ccb7-40bf-aec1-be71e4af525e#key-1"
],
"assertionMethod": [
"did:cheqd:testnet:804f2bd3-ccb7-40bf-aec1-be71e4af525e#key-1"
]
}
| * @internal | ||
| */ | ||
| @injectable() | ||
| export class TokenStatusListService { |
There was a problem hiding this comment.
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.
Signed-off-by: DaevMithran <daevmithran1999@gmail.com>
Signed-off-by: DaevMithran <daevmithran1999@gmail.com>
DaevMithran
force-pushed
the
token-status
branch
from
e2fbaab to
fbeda86
Compare
Signed-off-by: Pritam Singh <pkspritam16@gmail.com>
Signed-off-by: Pritam Singh <pkspritam16@gmail.com>
Signed-off-by: Pritam Singh <pkspritam16@gmail.com>
Signed-off-by: Pritam Singh <pkspritam16@gmail.com>
Signed-off-by: Pritam Singh <pkspritam16@gmail.com>
Signed-off-by: Pritam Singh <pkspritam16@gmail.com>
4 participants
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:
HttpTokenStatusListRegistryto publish and manage status lists via HTTP endpoints.Custom Registry Support:
Consumers can override the default behavior by implementing the
TokenStatusListRegistryInterfaceand configuring custom registries at module startup.Example: