add isue_credential and present_proof v3 for DIDComm v2 #2019
Conversation
Signed-off-by: judithmh <40442827+judithmh@users.noreply.github.com>
Codecov Report
@@ Coverage Diff @@
## main #2019 +/- ##
==========================================
+ Coverage 93.50% 93.61% +0.11%
==========================================
Files 539 592 +53
Lines 34666 38965 +4299
==========================================
+ Hits 32413 36478 +4065
- Misses 2253 2487 +234 |
|
@swcurran I would like to talk about this PR during the next Acapug call to give an update on where we are on DIDComm v2 implementation on Aca-Py. This PR covers the message structure required by DIDComm v2 (according to WACI Issue Cred and Present Proof v3). It still uses the old envelope. |
|
Sounds good. I assume you are involved in the Aries DIDComm V2 working group, and this will be raised/discussed there? I'm thinking from there we can discuss at an ACA-Pug meeting? |
|
Good discussion with @hkny at the first Aries-DIDCommv2-WG meeting today. It would be very interesting to canvas each agent implementation to see how they did/will handle this kind of transition. |
Signed-off-by: judithmh <40442827+judithmh@users.noreply.github.com>
Signed-off-by: judithmh <40442827+judithmh@users.noreply.github.com>
|
Kudos, SonarCloud Quality Gate passed!
|
| } | ||
|
|
||
|
|
||
| class LDProofCredFormatHandler(V30CredFormatHandler): |
There was a problem hiding this comment.
The formats are identical between DIDComm v2 and v3. I think we should try to reuse the handlers as much as possible to remove overhead. If something changes about the format, it needs to be updated in 2 places (3 now for indy)
There was a problem hiding this comment.
In AFJ we have the following model:
- Credentials Api provides interface to issue credentials. You provide a protocol version which indicates the protocol version, but the api is the same otherwise for all versions
- Credential Services are implemented for the different protocol version. The v1 protocol version has a hard depenency on the indy format and will throw an error if you try to issue a format that is other than indy.
- Credential Format Service provide the format specific implementation. This can be used by the credential services of different versions. The indy credential format service is currently being used by the v1 and v2 credential service and once the v3 credential service is added it will also leverage the indy format. This means the indy format is reused as much as possible and we get consistent behaviour whether you're using v1, v2 or v3.
Not sure if this is the approach ACA-Py wants to take, but I'm a bit worried about copying everything over when a new version is added instead of creating reusable abstract classes and interfaces.
There was a problem hiding this comment.
Thank you very much for your comment @TimoGlastra.
We went for the approach of creating the v3 folder after the decision in this meeting (the relevant minutes of the recording of the meeting are 15:45-21:40):
Maybe someone of the ACA-Py community could also have a look at the PR because I am not sure how to proceed now (next step would be implementing Out-of-Band for DIDComm v2).
There was a problem hiding this comment.
I think the discussion here is about the present proof v2 vs the present proof v3 implementation. These protocols are indeed different and I see the need for a separate implementation. However the attachment formats are separate RFCs 0592, 0593 & 0510.
The attachments have been extracted out of the issue credential / present proof protocols, with one of the reasons being that they could be versioned separately (i.e. a change to the issue credential protocol, doesn't require the attachment to be changed, and vice versa). Thus, the implementation for the format whether you're using v2 or v3 of the protocol is exactly the same. If a new format version is introduced it will require a new format implementation, but both v2 and v3 of the protocol could leverage that new version format.
For me it's on the same level that we don't have a separate implementation of the connection protocol whether we're using issue credential or present proof protocol. Connections are a separate RFC with a separate implementation that can be reused by other parts of ACA-Py. I see the same for attachments formats. You implement them once and they can be reused by different credential protocol versions.
|
Kudos, SonarCloud Quality Gate passed!
|
|
Looking at the current state of the issue-credential 3.0 protocol, it seems like the spec is lacking behind the recommended usage at the moment. The WACI-DIDComm spec is using a credential manifest attachment rather than attaching a credential preview to the offer, and there are some DIDComm v1 artifacts as well. I think we need to wait for that spec to be updated. https://identity.foundation/waci-didcomm/#issuance-2 |
|
There are a few challenges I see with this PR:
Unfortunately, I'm not sure I see a path forward for this PR as it stands. I acknowledge the significant efforts that went into it -- thank you @judithmh for your contributions. Thoughts, @swcurran @TimoGlastra @usingtechnology? |
As a group of university students we implemented the protocols issue_credential and present_proof for DIDComm v2. The encryption is currently still the same as for DIDComm v1. In addition to the tests of v3, the new endpoints can be tested using a DIDComm v1 connection for now. As soon as there is a decision on how to implement/extend the existing connection for DIDComm v2, the intention is to implement it and use its information regarding the DIDComm version for choosing the encryption type (and in case of DIDComm v2 to use the encryption which is already implemented in the askar wallet).