BAMF Summary - HackMD

# BAMF Summary - **What was the goal of the collaboration?** ([AP-101 Input document](https://bb.bamf.intern/projects/SSI/repos/ssi-docs/browse/BAMF-AP-prototype2/AP-101/solution-documents/input_documents?at=refs%2Fheads%2FChainedProof2021_specification)) - We started work with BAMF in the context of the AP-101 Work Package. One relevant input document outlining the use case can be found [here](https://bb.bamf.intern/projects/SSI/repos/ssi-docs/browse/BAMF-AP-prototype2/AP-101/solution-documents/input_documents?at=refs%2Fheads%2FChainedProof2021_specification). - The goal of this work package was to describe how the use case described in AP-101 can be realized using (interoperable / open) SSI specifications / technology. - We started by breaking down the use case requirements into concrete technical challenges. We were able to identify the following core areas of work (described [here](https://bb.bamf.intern/projects/SSI/repos/ssi-docs/browse/BAMF-AP-prototype2/AP-101/solution-documents/README.md?at=refs%2Fheads%2FChainedProof2021_specification)): - We need to define a specification compliant and interoperable way to include multiple signatures (e.g. Linked Data Proofs) in a Verifiable Credential. Furthermore, the order in which the different signatures were added needs to be verifiable and auditable. - We need to define / find a protocol which can be used to collect / request signatures (e.g. Linked Data Proofs) over Credentials from different signers. The solution should allow the requesting party to combine the received signatures in a single Verifiable Credential as they see fit. - We need to find an interoperable / well adopted protocol which can be used for issuing Verifiable Credentials. This protocol can be used to send the final ITSI-Antrag-VC issued by BAMF to the applicant's Wallet (step 10 from the sequence diagram included in the "Prozessbeschreibung für die Digitale Signatur"). - We then started our research work, attacking the individual areas outlined above. - **What was done?** ([solution documents are here](https://bb.bamf.intern/projects/SSI/repos/ssi-docs/browse/BAMF-AP-prototype2/AP-101/solution-documents?at=refs%2Fheads%2FChainedProof2021_specification)) - The core idea was to realize all data flows / interactions described in the input document using established / adopted SSI standards and specifications (as opposed to defining new specifications for this use case specifically). Furthermore, a further important consideration was that the proposed solution(s) should be easily implementable given existing SSI tooling / SDKs. - The first problem / use case to be solved was: - *"Once the ITSI application has been filled out by the organization representative (Vertr. Person), it needs to be signed and submitted for further processing / review. A signature (over the application content) will be requested from the representative (who can provide it using their Wallet application). The signature provided by the applicant will be verified, stored, and included in the final ITSI-Antrag-VC, issued once all processing / review steps have been completed, together with the signatures of other involved parties (e.g. BAMF employee who reviewed the application, specific BAMF department(s), etc..)."* - We suggested two potential solution documents, based on different underlying SSI specifications [[1](https://bb.bamf.intern/projects/SSI/repos/ssi-docs/browse/BAMF-AP-prototype2/AP-101/solution-documents/solution_0453.md?at=refs%2Fheads%2FChainedProof2021_specification), [2](https://bb.bamf.intern/projects/SSI/repos/ssi-docs/browse/BAMF-AP-prototype2/AP-101/solution-documents/solution_0586.md?at=refs%2Fheads%2FChainedProof2021_specificationd)]. Both solution documents describe a viable approach to solving this challenge (including interaction diagrams, associated open questions and next steps). We have then presented and contrasted / compared the two approaches. As a result settled we settled for [one](https://bb.bamf.intern/projects/SSI/repos/ssi-docs/browse/BAMF-AP-prototype2/AP-101/solution-documents/solution_0453.md?at=refs%2Fheads%2FChainedProof2021_specification) of the presented solutions, due to better standardization perspectives, as well as better tooling support. - The second problem / use case to be solved was: - *"We need to define a specification compliant and interoperable way to include multiple signatures (e.g. Linked Data Proofs) in a Verifiable Credential. Furthermore, the order in which the different signatures were added needs to be verifiable and auditable."* - In order to solve this issue we initially decided to use the [proofChain](https://w3c-ccg.github.io/data-integrity-spec/#proof-chains) property described in the Data Integrity (previously Linked Data Proofs) specification. Unfortunately we identified a number of issues in the specification document (documented [here](https://github.com/jolocom/BAMF-AP/blob/main/AP-101/resources/appendix_b_proof_sets.md#identified-issues-and-areas-of-future-work)), which made it impossible to use this property in an interoperable way. - In an attempt to gain some clarity on how these inconsistencies can be solved, we have reached out to the authors of the [Linked Data Proofs](https://w3c-ccg.github.io/ld-proofs/) specification via the following GitHub issue in the [relevant Github repository](https://github.com/w3c-ccg/ld-proofs/issues/26#issuecomment-821855653) (hosting the Linked Data Proofs specification). - It became quite clear that in order for the AP-101 flows to be realized in a spec compliant / flexible way, we had to tackle the issue of Credentials with a chain of multiple proofs. - We documented the next steps wrgt. solving the Chained Credentials issue in [this document](https://hackmd.io/_STYW6ZMQR--pJGcScFErQ#Standardization-efforts1) (work package 2). - We signaled our interest in moving the linked issue forward, and made some suggestions for potential solutions, posed open questions, and received positive feedback. - We came up with a very simple design document for a new type of Linked Data Proof, named `ChainedProof2021`, describing our proposed solution. - We then developed a prototype implementation of this specification using our Jolocom Library - We shared the design document in the relevant [github issue](https://github.com/w3c-ccg/data-integrity-spec/issues/26#issuecomment-1007257683), as well as with the W3C Credentials Community working group via the mailing list. We received positive feedback as well as interest from the broader community. - We used the lessons from building the prototype implementation + the received feedback to improve on our design document / implementation. - We prepared and documented a set of test cases / workflows showcasing the implemented prototype - **The github issue is still active, with various community members continuing on our initial effort (e.g. registering the appropriate JSON-LD contexts, developing further prototype implementations)** - **What were some of the issues / challenges** - The main overarching challenge we faced was still related to the maturity of various specifications / standards used within the SSI space. Namely, we encountered the aforementioned issue / inconsistency in the Verifiable Credential specification, making it quite difficult to realize use cases which rely on Verifiable Credentials with multiple proofs. The following two documents describe the open issues for different areas in more detail - Limitations in the Verifiable Credential specification (described [here](https://bb.bamf.intern/projects/SSI/repos/ssi-docs/browse/BAMF-AP-prototype2/AP-101/resources/appendix_b_proof_sets.md)) - Limitations in the Issue Credentials protocol (described [here](https://bb.bamf.intern/projects/SSI/repos/ssi-docs/browse/BAMF-AP-prototype2/AP-101/resources/appendix_a_attachments.md)) - **Demos / prototypes** ([link](https://bb.bamf.intern/projects/SSI/repos/ssi-docs/browse/BAMF-AP-prototype2/ProofChain2021?at=refs%2Fheads%2FChainedProof2021_specification)) - As previously mentioned, besides writing a specification for the new Proof Type (ChainedProof2021), we developed a prototype implementation based on our Jolocom Library, and showcased this implementation alongside a test suite - The demo project (alongside the updated version of our Jolocom Library) has been developed / maintained in the corresponding [BAMF Bitbucket repository](https://bb.bamf.intern/projects/SSI/repos/ssi-docs/browse/BAMF-AP-prototype2/ProofChain2021?at=refs%2Fheads%2FChainedProof2021_specification). As mentioned in the accompanying documentation, the repository includes: - The aforementioned specification for a new Linked Data Proof type, ChainedProof2021. - A modified version of the Jolocom Library, capable of generating and verifying the aforementioned proof type. - A set of specification compliance test, as well as anumber of example workflows making use of the newly developed proof type. - Upon running the demo application / associated tests, a report (outlining the distinct steps of the workflow and associated results) will be printed. **Example output can be [found here](https://hackmd.io/@RYgJMHAGSlaLMaQzwYjvsQ/H1zXskzcq).**