Attendees

• Vitor Pamplona
• Alex Fryer
• James Swinton-Bland
• Kaliya Young
• David Janes
• Rebecca Distler
• Jammal Dorsey
• Drummond Reed
• Bart Suichies

Agenda Items

Presentations

Recording

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

Meeting Recording:
https://zoom.us/rec/share/zIEDJ3IOxEAXtbNPTIIlNfniM2VIPI36WEwxK5QhEa8D2Qp9QhetBK_N1n20zk6g.thwzULKXTJ6bwbkD

Notes

1. Welcome and Linux Foundation antitrust policy

2. Data Minimization and Compression

• Need to determine payloads for credentials vs. passes
• Candidates:
• 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
• Create reference implementation to make sure it works 
• Trust registries / how to manage keys might have restrictions 
• 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

1. Investigate three options (with input from other GHP recs):

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