-
Notifications
You must be signed in to change notification settings - Fork 37
revamp vp formats #500
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
revamp vp formats #500
Conversation
c5818cd to
080ba3a
Compare
080ba3a to
d2edbe6
Compare
|
@OR13 given your experience with DataIntegrityProof, does the new ldp_vp syntax with proof_type_values and cryptosuite_values makes sense? (I will update the outdated examples) |
|
Looks ok to me. |
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
75f526e to
e25a5d0
Compare
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
|
WG discussion.
|
| The `vp_formats_supported` parameter of the Verifier metadata or Wallet metadata MUST have the Credential Format Identifier as a key, and the value MUST be an object consisting of the following name/value pairs: | ||
|
|
||
| * `issuer_signed_alg_values`: OPTIONAL. A JSON array containing fully-specified identifiers of cryptographic algorithms (as defined in [@!I-D.ietf-jose-fully-specified-algorithms]) supported for an `IssuerSigned` CBOR structure of an mdoc. If present, the `alg` COSE header (as defined in [@!RFC8152]) of the `IssuerSigned` structure of the presented mdoc MUST match one of the array values. If the `IssuerSigned` structure is not signed with a fully-specified cryptographic algorithm identifier (commonly known as a polymoprhic cryptographic algorithm identifier), the fully-specified algorithm derived from the combination of the `alg` value from the COSE header and the `crv` parameter from the signing key MUST match one of the array values. | ||
| * `device_signed_alg_values`: OPTIONAL. A JSON array containing fully-specified identifiers of cryptographic algorithms (as defined in [@!I-D.ietf-jose-fully-specified-algorithms]) supported for an `DeviceSigned` CBOR structure of an mdoc. If present, the `alg` COSE header (as defined in [@!RFC8152]) of the `DeviceSigned` structure of the presented mdoc MUST match one of the array values. If the `DeviceSigned` structure is not signed with a fully-specified cryptographic algorithm identifier (commonly known as a polymoprhic cryptographic algorithm identifier), the fully-specified algorithm derived from the combination of the `alg` value from the COSE header and the `crv` parameter from the signing key MUST match one of the array values. |
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.
mdoc device signed can be digitally signed or HMAC-ed. for HMAC-ed device signed, agreed to define identifiers in openid4vp specification
Co-authored-by: Paul Bastian <paul.bastian@posteo.de>
Co-authored-by: Paul Bastian <paul.bastian@posteo.de>
|
Okay so i understand what needs to happen before merge:
|
Co-authored-by: Paul Bastian <paul.bastian@posteo.de>
|
@TimoGlastra sorry if notes were not clear enough
|
Signed-off-by: Timo Glastra <timo@animo.id>
|
I updated the PR based on the feedback and main. With the merging of the vc and vp formats for W3C I also merged the |
|
wg discussion: ok to merge once @c2bo re-reviews |
Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com>
upon a verbal agreement that Martijn is ok for this PR to be merged conditional to his remaining comments around device_signed_alg_values are addressed
Supersedes #488
Fixes #495
Fixes #487
Dependant on #479 (it started from that branch due to the conflicts, once that PR is merged i will rebase). You can see the changes from this PR here: c5818cdvp_formatsandvp_formats_supportedfor each formatvp_formatsandvp_formats_supported.cryptosuiteto make it easier to query/define supported schemes (since most proofs will useDataIntegrityProofNOTE: this has breaking changes, but I think the previous definitions were really underspecified (and leaning on PEX), and not consistent. So I think it's worth it to make these changes before 1.0