Learn More →
did:sov
credentials.
The goal of this opportunity is to add full JSON-LD VC support to ACA-Py. ACA-Py already includes a, by default disabled, admin interface to sign and verify JSON-LD documents (and thus credentials). This support is limited to the Ed25519
signature type, and doesn't integrate with the credential exchange protocols.
The work will include:
Ed25519Signature2018
signature suite to issue and verify non-zkp credentialsBbsBlsSignature2020
/ BbsBlsSignatureProof2020
signature suites to issue and verify zkp credentialsdid:key
support to the admin api, adding BBS BLS key typesThe backchannel for Aries Framework Go (AFGO) only supports DID exchange at the moment, therefore we cannot test JSON-LD based credential exchange with AFGO. Extending the test harness and ACA-Py backchannel to support JSON-LD based credentials is in scope. If AFGO makes enough progress on their backchannel during the time span of this oppurtunity, we will make our best efforts to complete interoperability testing with AFGO using AATH.
In addition to the AFGO backchannel supporting the issue-credential and present-proof protocols, the following features can have an impact on the scope of interoperability testing:
The goal is to integrate with the presentation exchange format. However, as the work on presentation exchange has not started yet and because of the lack of a clear timeline, we're unsure we'll be able to accomplish this task in the given time frame. If presentation exchange isn't ready in the course of this project, a very simple workaround will be implemented to show agent-to-agent communication regarding JSON-LD credentials.
Because only Aries Askar has support for multiple tag values, the Indy non-secrets storage requires a different implementation. In order to complete the project in the given time frame the Indy implementation will be omitted for now. Andrew will look into this further.
Because it's hard to foresee the possible barriers when it comes to providing a unified issuance and verification API for both Indy and JSON-LD credentials, our implementation will initially focus on separate payload formats for the credential types. However, we will investigate this topic as part of this opportunity.
At the moment, interoperability with AFGO is more important than supporting the Credential Manifest standard. Therefore we will implement the issue credential format AFGO implemented.
Below a table is given showing what BBS+ related features are in scope for this project. ZKP and selective disclosure are definitely in the scope of this project. Revocation and ZKP predicates are definitely out of scope because these are still under development. Domain proof and required disclosure are to be determined based on the availability of these features in the BBS+ library. The table will be updated accordingly.
Capability | In scope |
---|---|
ZKP | YES |
Selective Disclosure | YES |
Domain Proof | MAYBE? |
Revocation | NO |
Required Disclosure | MAYBE? |
Integer ZKP Predicates | NO |
Projects related to this opportunity
Part of this opportunity is to show interop with at least one other framework. Aries Framework Go doesn't support the BBS+ signature suite for the credential exchange protocols yet. ACA-Py also doesn't support the presentation exchange attachment format yet. This means interop can only be partly shown, based on the progress of these features.
Feature | Interop |
---|---|
Presentation Exchange in ACA-Py | Ed25519 based credential issuance and verification between ACA-Py and AFGO |
BBS+ support for Presentation Exchange in AFGO | BBS+ based credential issuance and verification between ACA-Py and AFGO |
The four phases can be divided into two main groups which focus on non-ZKP and ZKP credential support. Below are the tasks that will be executed for each of the phases. Tasks will be described in greater detail before starting on the task at hand.
Phase 2 / 3
Phase 4 / 5
Present Proof still needs to be implemented in ACA-Py, however a lot of the work of the opportunity can be done in parallel to this work. The indy credential format and exchange protocol can only accommodate indy based credentials. To support the exchange of JSON-LD based credentials with support for predicates and selective disclosure the DIF Presentation Exchange will be used as described in RFC 0510: Presentation-Exchange Attachment format for requesting and presenting proofs
As part of the V2 version of the present proof protocol, the Admin API will extendend to support the new dif
(Presentation Exchange) format. This will mostly be in line with the presentation exchange format, removing fields that can be provided by ACA-Py, simplifying parts that can be abstracted in ACA-Py.
By providing mulitple formats in the Admin API a proposal/request for multiple proof formats can be provided. This allows the prover/verifier to select the preferred format to use.
Credential Manifest
With the addition for a new credential format some way to query and store JSON-LD based credentials need to be added to ACA-Py.
We can make use of tags to filter for credentials. Tags can include:
Multiple tag values can be used in Aries Askar, however not in the Indy non-secrets storage. This means the exact implementation of the query method / tag storage used is dependent on the underlying storage method.
To handle JSON-LD based credentials, we plan to create a few artifacts. The diagram below shows these components (shown in red) and how they relate to other, preexisting components (shown in green). A description of the components is given below.
This component holds the linked data proofs related functionality. Because ZKP requires additional functionality (e.g. framing), we've decided to split the functionalities of this component into two groups: ZKP and NON-ZKP (e.g. Ed25119).
We plan to make the architecture in a way that it allows for pluggable signature suites. These suites can then vary in the canonicalization, digest and proof algorithms they use.
This component wraps Ursa's BBS+ related functionality so its accessible from withing Python. There is a repository ursa-bbs-py created by Andrew that wraps Ursa's BBS+ functionality, but it's slightly outdated and uses PyO3 to generate the Python bindings. MATTR Global has an ffi-bbs-signatures repository that currently holds fast-forward interface wrappers for both .NET and Objective-C. We think it would be best to add a Python wrapper to this repository and use that instead of the ursa-bbs-py
repository.
Whats missing:
Context URLS
The issue credential method issues a credential by adding a linked data proof to the credential document. The steps include:
vc.js
and vc-js
)jsonld-checker
)Additional tasks:
The verify presentation method verifies a verifiable presentation and its credentials. The steps include:
vc.js
and vc-js
)This is TBD. The derive proof will be used for BBS+ signatures. Important to note that no private key is needed to derive proof (at least for the unbound signature proof)
Input:
{"method": "key", "options": {"keyType": "ed25519"}}
{"method": "key", "options": {"keyType": "bls12381g2"}}
{"method": "sov"}
(default)Path for BBS inside AFGO: pkg/doc/signature/suite/{bbsblssignature2020, bbsblssignatureproof2020}