You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When you use the default type Record<string, unknown> this causes issues for nested frames.
So let's say I dezerialize an SD-JWT ey123.ey123.ey123~123~456~ into a sd-jwt the types for Header and Payload will be Record<string, unknown>.
If I now want to do create a presentation frame (or disclosure frame, they're based on the same base frame) it will result in errors If I use a nested object:
{// errors as 'nested' key is expected to have boolean | undefined valuenested: {claim: true}}
I think when we don't know the value of something (= unknown) we should not say the value should be boolean, but rather it can be an array with booleans an objects with new key values or a boolean, as we don't know the structure of the object
The text was updated successfully, but these errors were encountered:
I think that makes sense, yeah. When I designed the API I think I had the issuer mainly in my mind, which does not encounter this issue as the type of the payload is always complete. But from the holder or verifier, some of the values might be in the disclosure array.
When you use the default type
Record<string, unknown>
this causes issues for nested frames.So let's say I dezerialize an SD-JWT
ey123.ey123.ey123~123~456~
into a sd-jwt the types for Header and Payload will beRecord<string, unknown>
.If I now want to do create a presentation frame (or disclosure frame, they're based on the same base frame) it will result in errors If I use a nested object:
I think when we don't know the value of something (=
unknown
) we should not say the value should beboolean
, but rather it can be an array with booleans an objects with new key values or a boolean, as we don't know the structure of the objectThe text was updated successfully, but these errors were encountered: