2021-05-05 Paper Based Credentials Drafting Group Meeting Notes

Time	Item	Who
2 min	Welcome & Antitrust Policy Notice	Chair
25 min	Data Minimization and Compression	David and Vitor
30 min	EU Alignment Concerns	Bart
3 min	Wrap up	Chair

Topic: Good Health Pass - Paper Credentials
Start Time : May 5, 2021 11:00 AM

1. Welcome and Linux Foundation antitrust policy

2. Data Minimization and Compression

LD proof (with and without JSON xt?)
CBOR-LD (still a work in progress, but could be well used in the future)
CBOR will restore the field name and information (so if field names are big, it takes up space on binary as well); if use LD the field name converts to a number (field name space not occupied anymore); in order for that to happen, field names must match vocab from W3C (which isn’t complete yet)
Decision: Look at CBOR-LD and see if it meets requirement

If we decide that the QR code has to be a valid URI, there’s not too many options - CBOR-LD an option, but if CBOR-LD does not work or does not allow us to flexibly add new fields...
Look at a few recommendations:

Pathcheck
JSON-LD
SMART cards
EU proposal - but would be constrained to what they’re defining (they use ZLIB and CBOR web token) but let’s not create a new one

Look at transformation to Pathcheck (one way transformation); JSON-xt easy to implement (will put something on GitHub)
Can say unless you use one of these, the method of compression won’t be good enough
- EU divergent because of PKI - once anyone has decompressed into data and validated signature and gets to the rules engine side - basic data compatibility level, all playing in the same sandbox
- ZLIB, CSOR - EU came up with something unique to them (unique code path)
- Use uri schema - define compression mechanism and read QR
- Need to work with universal DID resolvers

3. EU Alignment Concerns

“Europe is not going to have a good health pass” - does this disqualify GHPC?

No way to achieve EU compatibility in a general worldwide sense
If we stop specifying, EU is “ghpc compliant” but if we go deeper, they won't be
Clear path for someone to implement and verify GHP presented credentials - and specify right to the bit level. EU health pass can be consumed into the ecosystem.

Example: people are coming into Spain from all over the world. Verifier is almost certainly a commercial entity, has signed off to take in passes from all over the world. High levels of data compatibility - yes we specify that a GHP looks like this, but here’s how we get from a bunch of data and translate it into a QR code, that verifier in Spain can consume a GHP

Not fighting on issuing - Singapore, EU, Israel have made decisions on what they’re using - where we’re creating the most value is for the places that have not decided how to do this, based on local data needs, coding needs, local PKI needs

Apply principles about what should be done
GHP is as privacy-preserving as possible, the world is as it is - can’t pretend everyone will do those things - systems in place around international travel will need to consume things - we’re trying to push the market in a certain direction by saying “this is the best way to do it”

Can have an opinion about your competitor, but they have no incentive to play with you
Difference between standards compliance and interoperability - you can be “certified GHP” (make sure whatever system implementation is, it’s a GHP); second is are you interoperable with other health pass implementations?

Narrative group has work cut out for them - most European citizens may not recognize the difference
Either we say that the EU certificate is or is not compliant - how could a non-compliant thing be consumed in our ecosystem? It goes through filtering and transformation process
Implementing different schemes to verify - having to add a verifiable GHP is going to be extra work

Canada is aligning with the GHP path with JSON-LD ZKP BBS+
Need to get leads to discuss
Gap analysis between medcreds and this; roadmap to BBS+ add paper credentials, think through how much we want to do on rules engine and trust registry - start a gap analysis

Action Items

QR = "JXT:" + JXT(template, BBS+LD-Proof(JSONLD, keyID)) -> JsonXT

QR = "CRED:"+ PathCheckBBS(template, data, keyID)-> PathCheck

QR = "VP1:" + Base32URL(CBOR-LD(template, BBS+LD-Proof(JSONLD, keyID))) -> DigitalBazar

Space shortcuts