hyperledger
feat: add new format and implement VCDICredFormatHandler
- add VC_DI in CredFormat.Format
- lay out VCDICredFormatHandler
- add new schema classes for cred offer and request
- implement CredExRecordVCDI
- fix schemas on cred_abstract and cred_request, improve on vc_di support on alice-faber demo
next step
fix unittests issues
Note: this is a rebased version of @tra371 's pr #2759
Overall this looks good to me, but do we also want to add some readme/markdown about what VC_DI is and how to get the verifiable credential out or how it can interoperate with other wallets? we could also do that separtely from the repo or later, but i'd like to make sure new folks have an idea why, when and how to use them?
@dhh1128 would greatly appreciate (and recognize) your guideance here to get this over the line nicely, if you have any suggestions.
@ianco do we care that we don't have codecov? should we worry if we actually covered all the new stuff?
ha i will stop being noisy now - thanks all for feedbacks!!!
@ianco do we care that we don't have codecov? should we worry if we actually covered all the new stuff?
Personally I'm not too concerned about the level of code coverage as long as we have good integration tests. However we do need a minimal set of unit tests to confirm that the code works. I did a quick review of the code and it doesn't look like there are any new tests (?) in this PR yet.
Regarding the broken tests, many are throwing a "StopAsyncIteration" error - for example:
./scripts/run_tests aries_cloudagent/protocols/issue_credential/v2_0/tests/test_routes.py::TestV20CredRoutes::test_credential_exchange_issue
... raises this error. I'm not sure the cause (it's raised during a "mock" call) but I suggest we focus on getting the demo working (see my comments about the credential proposal format), and once we confirm the demo is working properly we can revisit the tests.
@ianco do we care that we don't have codecov? should we worry if we actually covered all the new stuff?
Personally I'm not too concerned about the level of code coverage as long as we have good integration tests. However we do need a minimal set of unit tests to confirm that the code works.
mmm yeah usually I am lazy and start by looking at the codecov report, to make sure those unit tests are added. @tra371 if you are back on do you want to try to just add some tests, or maybe run a quick local codecov and see where we are at - we need to make sure new code has tests; @supersonicwisd1 if you can focus on getting the demo working manually that might be good since you have it going
We did pass the integration tests which run alice-faber so we should be close now...just need the real presentation format maybe
We did pass the integration tests which run alice-faber so we should be close now...just need the real presentation format maybe
There aren't any integration tests for the new VC_DI format tho ...
Declaring some of my assumptions as preamble to a question:
- VCDI format supports many credential formats
- First target format to support is AnonCreds in W3C format
As currently structured, this strictly supports only AnonCreds format, right? In the future, what will be required to add support for issuing, say, DIP-VC or JWT-VC? Is there anything we can or should do now to make that easier for us later?
As currently structured, this strictly supports only AnonCreds format, right? In the future, what will be required to add support for issuing, say, DIP-VC or JWT-VC? Is there anything we can or should do now to make that easier for us later?
Keeping in mind that this initial work is being done under a Code With Us (https://marketplace.digital.gov.bc.ca/opportunities/code-with-us/7afcbd7c-2bbc-41ed-bf27-b6ba6e2903c5) we need to be mindful of scope creep. @swcurran what do you think? My preference would be to keep the initial use case as simple as possible.
As currently structured, this strictly supports only AnonCreds format, right? In the future, what will be required to add support for issuing, say, DIP-VC or JWT-VC? Is there anything we can or should do now to make that easier for us later?
Keeping in mind that this initial work is being done under a Code With Us (https://marketplace.digital.gov.bc.ca/opportunities/code-with-us/7afcbd7c-2bbc-41ed-bf27-b6ba6e2903c5) we need to be mindful of scope creep. @swcurran what do you think? My preference would be to keep the initial use case as simple as possible.
We're more than happy to structure for future extensibility, not concerned with scope creep if we can possibly complete after the formal approvals (once we get to there!)
do you guys have specific suggestions about structuring this for extensibility?
Agree that we will need future extensibility with this, so if there are some things that are obvious and easy, let’s do them. But highest priority is delivery the AnonCreds in W3C VCDM, so that’s the current focus. I can’t answer Golda’s question about specifics to do, but if others have suggestions, please add them. Thanks!!!
I should add that the goal would be to transition from the existing 0592 and 0593 Credential Attachment RFCs for both legacy AnonCreds and JSON-LD VCs (and 0771 AnonCreds) to the VC-DI attachments. It will take some time, but that is the goal.
, DIP-VC or JWT-VC
hey @dbluhm we are definitely interested in this after we get the first stage working, if we can plan a sync to understand your thoughts on it. @tra371 @clehner
@gvelez17 I was hoping you might have recommendations for where the right points in the implementation would be to extend later to support other credential formats and signature types.
@gvelez17 I was hoping you might have recommendations for where the right points in the implementation would be to extend later to support other credential formats and signature types.
hey Daniel is this still relevent based on the conversation in Anoncreds working group today that V2 will always default to a W3C compliant format? Are we moving more towards a consensus format rather than ability to plug in many? Happy to still look at this however will give some suggestions
Quality Gate passed
Issues
0 New issues
0 Accepted issues
Measures
0 Security Hotspots
No data about Coverage
No data about Duplication
See analysis details on SonarCloud
![sonarqubecloud[bot] avatar](https://avatars.githubusercontent.com/in/12526?v=4 "Published by a pub.dev verified publisher"){kind=small}
@gvelez17 I was hoping you might have recommendations for where the right points in the implementation would be to extend later to support other credential formats and signature types.
hey Daniel is this still relevent based on the conversation in Anoncreds working group today that V2 will always default to a W3C compliant format? Are we moving more towards a consensus format rather than ability to plug in many? Happy to still look at this however will give some suggestions
Yes; the VCDI credential attachment format is explicitly capable of issuing credentials with multiple cryptosuites, of which, AnonCreds is just one variety. We will want to be able to support signing credentials with other cryptosuites besides just AnonCreds.
New PR: https://github.com/hyperledger/aries-cloudagent-python/pull/2861
Closed in favor of https://github.com/hyperledger/aries-cloudagent-python/pull/2861