Open TimoGlastra opened 10 months ago
If we change the current interface form
public async verify(
verifySignature: Verifier<Header>,
requiredClaims?: Array<keyof Payload | string>,
publicKeyJwk?: Record<string, unknown>
): Promise<JwtVerificationResult> {
public async verify(
verifySignature: Verifier<Header>,
requiredClaims?: Record<string, unknown>, // <---- note its just an object now
publicKeyJwk?: Record<string, unknown>
): Promise<JwtVerificationResult> {
and the user can pass in an object which must be inside the JWT, would that suffice?
Yeah that sounds good!
How about required keys of which you don't know the values beforehand?
I think using some constant of SdJwt.Any
might work. the SdJwt.asertClaimInPayload
takes a claim key and value, but that will ignore the nesting.
{
"nonce": "123123123123",
"iss": SdJwt.Any,
"address": {
"street": SdJwt.Any,
"zipcode": "1231AA"
}
}
So it would be something like that
Makes sense 👍
JWT libraries I've used in the past (such as
jsonwebtoken
allow you to pass anonce
(as well as other values such asaud
) to the verification method and it will be checked against the value in the JWT.Is that something we can add to this library as well?
I wanted to add it from the SD-JWT KB level up (as SD-JWT KB requires
nonce
andaud
to be present), but I was running into a problem that the methods all extend theverify
from the class they extend and thus we can't really change the parameters for the higher level classesThis seems like a limitation to me that isn't really beneficial as it makes sense that you want to provide more parameters to the SD-JWT VC verify method than you do to the JWT verify method. I think this is mainly if the number of arguments change and it would be fine if we make it a single options object that can be extended with multiple layers.
Something like this: https://www.typescriptlang.org/play?ssl=23&ssc=19&pln=23&pc=37#code/JYOwLgpgTgZghgYwgAgFIHcwDVrBgTwHkAHMYAexAGdkBvAKGWWCqoH4AuZKsKUAc0bI4AVwAmnbrwFCQlJJJ58QggL716CADZxWaTHSEA3XAQAU5UhWpcM2U0SuUqASkNMmQ9evqhIsRBQAZTE7HD4CEjJnZAgAD0gQMRowhyjrGgYmAGsIfAAhUDEBSSyPORAFLiUZD2FxRWkVL3ofbV0aELtYhIgklIMy7IAjboBeZBAIdH0wMxcNJhMI-AsnG2QuzHC8R2jqNzKmKhFiaAA6Zd21-ddFjzAACxZzkbtLhzMjj1ExLktbq88oUkiVzr8ADRCOoVJD-dZUIEFIpg2EQaHIVQLJjeIA
Not fully happy with it, as it means all properties exposed on
JwtVerifyOptions
(such asaud
andnonce
are now also exposed in SdJwt verify method (but you don't want to check these in the SD-JWT credential, but rather in the KB-JWT)