Next steps

[ineiti]

Two next steps:

• [x] work on the elfa infrastructure
  • [x] get it to work end-to-end with either the Android or the iOS app

- [ ] apply the testing suite from https://github.com/w3c/vc-data-model-2.0-test-suite to the data structures coming out from the backend / being exchanged between the backend and the frontend

• [x] Open an issue in the ELFA repo with our questions

ELFA End2End challenges:

• [x] System is only installable on a Linux environment
• [x] API scenarios are not documented, and no examples are given anywhere. 2024-05-14
• [x] Networking issues to connect phone in a LAN to issuer inside WSL2 on a windows machine behind a windows defender firewall.
• [x] App is not recognizing issuer 2024-05-24
  • issue created
• [x] App crashes now - needs to start up correctly 2024-05-29
• [ ] Propose forked version of elfa for other people to try out

Goal: finish by 11th of July

[ineiti]

While waiting on OFIT's answer, start with 1.

Wait until end of week for the android wallet.

[lanterno]

We got a reply from Andreas Frey Sang on Monday evening:

Hey Ahmed

Thanks for your mail. I can only re-iterate how happy we are, over C4DT and EPFL’s interest in the E-ID program!

Christian and I quickly spoke regarding your request.

Just for your information The new pilot implementation (based on the learners driver license), is not based on the indy sandbox. If you want to test it, you will have to operate the “infrastructure” as well (https://github.com/e-id-admin/eidch-pilot-elfa-base-infrastructure) – but as I gathered from your Github feedback you are already on it 😊

Further adaptation by EPFL We are obviously always interested for you to use and extend our implementations. (As well as sharing your learnings in blog posts or at a participation meeting https://www.eid.admin.ch/en/why-do-we-need-participation. As you might know we started the implementation of the recently published pilot a while back. Even before the technical advisory circle started – hence it’s focussed on a simplified version of the EU-Stack.

Since the technical developments in the SSI-community are progressing very swiftly, further exploration of approaches like one based on BBS+ are definitely appreciated. If you want to push it further, you could even have a look at cryptographic layering: The new W3C Draft on Data Integrity https://www.w3.org/TR/vc-data-integrity/ opens the option to attach multiple signatures to the same VC (e.g. PQC as well as privacy preserving BBS+). If you want to tackle this, potentially interesting insights could be generated. We will most likely be experimenting further with BBS+ Credentials anyway (just FYI).

We also hope to launch a new sandbox/public beta sometime early next year, which will aim to offer the initial infrastructure used by the productive ecosystem.

Regarding Android Yes this should be available soon. I reached out to the development team but haven’t heard back yet. I will let you know as soon as I hear back from them.

If you have any further questions feel free to contact us.

Kind Regards, Andreas

[lanterno]

On Tuesday April 16, I discussed it with Linus, and we decided to explore the W3C specification as suggested by Andreas. I read the specification, and here's a conclusion based on what I've read:

The Verifiable Credential data integrity W3C standard

It’s a draft standard for encryption-based mechanisms that guarantee the authenticity and integrity of verifiable credentials.

There’s two important points that I can mention:

1. It provides specific algorithms for VC hashing/ signing/ verification that are independent from the encryption algorithm itself. It accepts encryption algorithms are plugins.
2. It allows for chaining signatures/ proofs of the VC. This allows for VCs that need to be signed/ issued by more than one entity; think of a business contract with multiple signatures required.

Conclusion: From the information we have so far, we can deduce that the e-ID team is considering implementing this specification in a library that can then use BBS+ or other signatory schemes. Since BBS+ would be a pluggable proof format in that case, it can be changed/ updated in the future with other schemes (called crypto suites).

Further exploration:

I haven’t found an implementation of the mentioned standard. reference: https://github.com/w3c/vc-data-integrity

There’s a BBS+ Crypto suite specification mentioned at https://github.com/w3c/vc-di-bbs

Verifiable credential data model https://github.com/w3c/vc-data-model

[ineiti]

Questions for possible next steps:

• how are the vc-data-integrity and vc-di-bbs linked:
  • is the vc-di-bbs in fact an implementation of the vc-data-integrity?
  • what do the acronyms mean? CR / FCGS / FPWD / CGFR? Are they general terms by the W3C, or vc-di specific?
• how to fit this in the elfa pilot?
  • just have the backend
  • vc-di-bbs is in go, ts + rust, elfa is in python

Other Ideas:

• create a project with OFIT to implement the vc-di, together with a lab, as Open Source project -> @ineiti discuss with people from OFIT, then Carmela, Vaudenay, or Bryan, or Yanina Shkel
• easier, smaller possibilities
  • implement BBS+ in the elfa code
  • adjust the demo to our use-case

[lanterno]

is the vc-di-bbs in fact an implementation of the vc-data-integrity?

No, it's a specification for a cryptosuite which is one component of the VC-DI specification. I could confirm by checking the specification which mentions completely different APIs. However, it's not clear if this repo implements only the cryptosuite or the whole thing: https://github.com/mattrglobal/jsonld-signatures-bbs

what do the acronyms mean? CR / FCGS / FPWD / CGFR? Are they general terms by the W3C, or vc-di specific?

FPWD: First public Working Draft CR: Candidate Recommendation

FCGS and CGFR: no idea! but they seem to be general terms. Also, all file names are general to the specification.

• how to fit this in the elfa pilot?
  • just have the backend
  • vc-di-bbs is in go, ts + rust, elfa is in python

This repo might be usable https://github.com/mattrglobal/jsonld-signatures-bbs (Typescript).

[lanterno]

• With some digging into the test files, I managed to understand how to use the API to issue a credential offer
• Solved networking on WSL2 and phone in LAN proved to be rather challenging. Is there a way to make phone see localhost?
• After getting all parts to work, we still see a weird message on the app. I'm written an issue on the app repo here https://github.com/e-id-admin/eidch-pilot-android-wallet/issues/1

[ineiti]

• Networking on WSL2 and phone in LAN proved to be rather challenging. Is there a way to make phone see localhost?

What most people do is to run the server in a docker, and then expose that port. You'll have to do it once in docker (-p) or docker-compose (ports:), then probably Windows will pick it up and ask you whether you want to expose that port. After that you should be able to connect using your Windows hosts public IP address.

Else I still have that linux laptop in my office, if you want to use that.

[lanterno]

Else I still have that linux laptop in my office, if you want to use that.

No need, it's already solved as I mentioned "implicitly" in my 3rd point above.

For reference, I solved the problem on a couple of steps:

• Docker compose already did the port mapping
• Windows automatically maps the ports to localhost (but that's it)
• Retrieve WSL2 machine IP:

  ip addr show eth0

• I then had to expose the ports on Windows using: (for each port)

  netsh interface portproxy add v4tov4 listenport=XXXX listenaddress=0.0.0.0 connectport=XXXX connectaddress=MY_WSL2_MACHINE_ID

• Set a exception rule in the windows defender firewall for the ports 8000 to 9000

[ineiti]

Look at the tech roadmap for next steps:

https://github.com/e-id-admin/open-source-community/blob/main/tech-roadmap/tech-roadmap.md

[ineiti]

Say why the verification did not work out, and why publishing the changes doesn't make sense.

[lanterno]

Last updates on the ticket: @ineiti I spent 2.5 days on the following:

• I managed to add the diploma VC to the list of available VCs on the ELFA backend, confirming that the ELFA server supports adding other VCs in addition to the ones that come with the project.

• I confirmed with ELFA mobile team that the current version of the app is built only for ELFA and not other VCs. Next version

• I used the (web) test wallet to display the different VCs including the one I added above.

• I moved later to use the VC test suite:

  • The VC test suite depends on the API using a standard from the following specification https://github.com/w3c/vc-data-model-2.0-test-suite which is not followed.
  • I also compared the API response format I got from the ELFA API, and the one expected in the test suite documentation and they didn't match
  • After seeing all this, it's obvious that ELFA was targeting something else that this test suite is not testing. However, I don't know if the test suite is too specific, or ELFA is too deviant. (This would require a lot of reading to figure out)

• As for the final requirement of sharing my code modification. My work on installation script could've been shared, but as we advised the E-ID team on it, they already incorporated a fix.

• Other changes were targeted at making the project work for me, as some features like API tokens just didn't work our of the box for me. However, these things would need good documentation rather than just removing them like I did locally.