feat: add w3c-di-attach #809
Conversation
Signed-off-by: Timo Glastra <[email protected]>
Signed-off-by: Timo Glastra <[email protected]>
Signed-off-by: Timo Glastra <[email protected]>
|
Tested the w3c credentials and presentation vectors from |
Signed-off-by: Timo Glastra <[email protected]>
| ```jsonc | ||
| { | ||
| "anoncreds_link_secret": { | ||
| "entropy": "<random-entropy>", |
There was a problem hiding this comment.
i think the cred_def_id is missing here aswell
|
|
||
| ## Motivation | ||
|
|
||
| The Issue Credential protocol needs an attachment format to be able to exchange W3C verifiable credentials. It is desirable to make use of specifications developed in an open standards body, such as the [Credential Manifest](https://identity.foundation/credential-manifest/) for which the attachment format is described in [RFC 0511: Credential-Manifest Attachment format](../0511-dif-cred-manifest-attach/README.md). However, the _Credential Manifest_ is not finished and ready yet, and therefore there is a need to bridge the gap between standards. |
There was a problem hiding this comment.
Not crucial, but it seems odd to not mention the 0593 JSON-LD Attachment format in this section -- and that as it is defined it is insufficient for current needs, and the transition from Linked Data Proofs to Data Integrity proofs is also needed.
There was a problem hiding this comment.
Good point, will add some extra wording
|
Looks good -- nice work! The pending implementations will allow us to learn about the formats and clarify/adjust this as needed -- either before or after merging. |
|
WG 20240124. In implementation phase now in ACA-Py. |
|
@TimoGlastra / @auer-martin -- the last commit you did had non-DCO content. Could you correct that? Thanks! |
Signed-off-by: Timo Glastra <[email protected]>
Signed-off-by: Timo Glastra <[email protected]>
Signed-off-by: Timo Glastra <[email protected]>
…value Signed-off-by: Timo Glastra <[email protected]>
TimoGlastra
force-pushed
the
feat/add-w3c-di-attach
branch
from
1968d1b
to
30fbd50
Compare
|
Done |
|
@TimoGlastra @auer-martin --- anything to add to this after implmenting the attachments? All good? Thanks! |
|
I think everything should be fine. |
|
|
||
| ## Rationale and alternatives | ||
|
|
||
| [RFC 0593: JSON-LD Credential Attachment](https://github.com/hyperledger/aries-rfcs/blob/main/features/0593-json-ld-cred-attach/README.md), [W3C VC API](https://w3c-ccg.github.io/vc-api/) allows issuance of credentials using only linked data signatures, while [RFC 0592: Indy Attachment](https://github.com/hyperledger/aries-rfcs/blob/main/features/0592-indy-attachments/README.md) supports issuance of AnonCreds credentials. This attachment format aims to support issuance of both previous attachment formats (while for AnonCreds it now being in the W3C model), as well as supporting additional features such as issuance W3C JWT VCs, credentials with multiple proofs, and cryptographic binding of the credential to the holder. |
There was a problem hiding this comment.
allows issuance of credentials using only linked data signatures
The capabilities of the VC API are expanding. We wanted to start with a concrete end-to-end flow using a narrow profile (just Data Integrity Proofs and W3C VCDM), but given that the VCDM v2.0 now supports arbitrary credential formats, and given that those arbitrary credential formats can (theoretically) just slot into the VC API (the verifiableCredential and verifiablePresentation objects can contain arbitrary credential formats, it is (theoretically) possible to use the VC API to issue/verify/derive alternate credential formats.
We still need to do a lot of work to make that clear in the specification, and we're behind on the VC API because all of our effort is going into completing VCDM v2.0 and Data Integrity v1.0 now. Once that's done (in the next couple of months), we'll shift our focus into opening the aperature for the VC API. @PatStLouis is engaged over there and so I expect that we'll be able to align given his engagement in multiple groups.
I don't think this changes the very good work that each of you are doing... just signalling a direction if it helps to coordinate on this aspect.
There was a problem hiding this comment.
The credential attachment outlined here is specific to didcomm issuance/requests. While the json-ld attachment was initially designed around the vc-api, this was back in 2019 and does not represent the current state of the specification. However, the vc-api will still have shortcomming when dealing with holder binding negotiations (such as requesting a holder link secret bind with the anoncreds-2023 crypto suite).
From what I see the attachment proposed removed the options field in favor of the following:
{
"data_model_versions_supported": ["1.1", "2.0"],
"binding_required": true,
"binding_method": {
"anoncreds_link_secret": {
"nonce": "1234",
"cred_def_id": "did:key:z6MkwXG2WjeQnNxSoynSGYU8V9j3QzP3JSqhdmkHc6SaVWoT/credential-definition",
"key_correctness_proof": "<key_correctness_proof>"
},
"didcomm_signed_attachment": {
"algs_supported": ["EdDSA"],
"did_methods_supported": ["key", "web"],
"nonce": "1234"
}
}
}
There is a lot of format negotiation included in the didcomm issuance rfc which is not really in line with the prescriptive approach of the vc-api model. This being said, these fields could be included as options in a vc-api workflow without issue.
The credential omissions in this rfc are in line with what is discussed during the vc api calls:
- issuer
- issuanceDate
- credentialSubject.id
- credentialStatus
afaik this is aligning nicely with the direction of the vc-api
Attachment based on the new Data Integrity Proof specification.
Some notable highlights: