2021-04-07 Paper Based Credentials Drafting Group Meeting Notes

Attendees

• Tony Rose
• Bart Suichies
• Drummond Reed
• Travis James
• Marie Wallace
• Chatchai
• David
• Erica Frenkel
• Kaliya Young
• Lucy Yang
• Ramesh Raskar
• Sankarshan (Dhiway)
• Sara Facchinetti
• Sid
• Sumiran
• Vitor Pamplona

Agenda Items

Presentations

https://docs.google.com/document/d/1AYZTafvQLPY5m4Cl471JqR2WR3t7Riu-rYAfxGdq62E/edit#

Recording

Topic: Good Health Pass - Paper Credentials
Start Time : Apr 7, 2021 10:56 AM

Meeting Recording:
https://zoom.us/rec/share/BV57WwFt78QEhqdw8x8dJWKhSBFP6Vlsf4dowMrQbzbOdc2zk7ich0rd0hZFeF5z.Df34tOfyDodA2asv

Notes

1. Welcome and Linux Foundation antitrust policy

2. Consensus Points 

1. Consensus needed: our primary goal should be to answer the KIQs. 
1. I believe we have a satisfactory answer right now for [KIQ2] - that we’ll have a “full credential” recommendation and an even smaller “pass” for super constrained environments. We can revisit this as we learn more about further answers (SEE DISCUSSION BELOW)
2. Consensus needed: I feel this is obvious, but this is about “staying on target”. Although our technology has broader application for encoding credentials, our goals are to support efforts done elsewhere in GHP, in particular:
1. we are encoding credentials defined by GHP [KIQ2, also affects KIQ6]
2. we are using trust frameworks defined by GHP
3. we are using digital signature methods defined by GHP [KIQ3]
4. we are using identity binding methods defined by GHP
5. Additional Q: Will GHP put forward recommendations or requirements? Need to gain consensus across drafting groups

3. Definition of Credentials v. Passes

• Potential key attributes of a Pass
  • Pass = VC or proof/presentation or could be both?
  • Pass could be as simple as a proof/presentation that is some proof of info in credential
  • Pass is a presentation of derived credentials (e.g., in case of EU digital green pass, there are 3 VCs - vaccine, test, recovery - and the pass is the presentation of one or more of these VCs)
  • A pass is applicable to a specific use-case (e.g., getting on a plane), which could be in the form of a presentation (where this can be extended) 
  • Results of producing a pass depend on time of presentation on whether you fit criteria or not - making that distinction helps build an ecosystem around it
    • Requirement may have changed by the time pass is used
    • Need to have it dynamically changed (e..g, credential based on time you got it, idempotency may help us frame this 
  • Pass has been run through a rules engine - step of processing that distinguishes them?
  • Give access to something; discloses information that needs to be verifiable
  • In end state, will passes just be proof presentations? Can't have a single pass that applies to everything 
• Potential key attributes of a Paper Pass
  • Not necessarily proof/presentation
  • Paper will have its own constraints - need to distinguish between paper and digital 
  • Something that doesn’t have transformation into a digital credential;
    • Pass is for hyper constrained environments and does not need to be two-way
    • You may not get the vaccination credential (primary proof) 
  • Results of presenting a paper credential are the same
  • Expand definition of pass to be a QR or presentation or VC defined on paper? 
  • DIVOCC is a vaccine credential - if the rule is that you must show proof of vaccination, then it can also serve as a pass
• Potential key attributes of a Credential
• Under the GHP definitions, a credential is sourced from the issuer of record for the credential type (Vaccine, Test result, Recovery).
• Is it a primary credential or is it a secondary credential issued just for a specific context (e.g., IATA TravelPass)
  • Do secondary credentials = attestations?
    • An app, rules engine, or issuer could produce a secondary credential
• Are secondary credentials = attestations? An app, rules engine, or issuer could produce a secondary credential
  • Primary credential is coming from a trusted lab or healthcare provider - whoever is attesting to the source (medical/health data) secondary credential comes from not the original source of health data
  • Could also have the primary source issue the "pass"
  • Could be a VC or set by business logic - in some use cases, the "pass" may just be the credential
    • E.g., New York - I request excelsior pass, which is generated based on business requirements 
    • It's a lot of moving parts to get proof/presentation working, so in the shorter term people go simpler route
    • We want them to understand this is option A but option B gives you a more self sovereign way of doing it
  • When digital kicks in with EU, could start to roll in proof/presentation because they have a digital option - may not be able to do it for paper, but could for digital 
• The credential is the source data that this pass comes from. The benefit of a presentation is being more dynamic. The benefit of a pass is that it's fixed (but hard to prevent replay attack)
• On use cases where you don’t have complete info on that credential (which today, is most of them - don’t really have signed payloads; the rules engine doesn’t have enough info to process the pass) - proof presentations as “pass of the future”
• Passes vs. credentials are based on the definitions used by GHP and then further constrained within this group; passes only need to go from data to pass (really for constrained environments)
• What is shown in a paper format is up to this group
• Needs to map to user journey
  • In the end, how can we convert from paper to pass?
  • Having clear definitions important - expand definition of pass to include PathCheck and DIVOCC on paper rather than coming up with nomenclature
• Define interoperability guidance for other QR codes and non-VCs

• POTENTIAL NEXT STEPS ON DEFINITION: 

• Keep pass simple (derived data); the process of derivation may be through execution of business rules OR the response of a proof presentation; some people might want to switch back and forth
• Do we have paper passes and digital passes (digital derived from VC but paper pass does not need to be?)
• Expand definition of pass to include on paper QR codes that are signed data with trust registry 
• Differentiate between purely paper-based or paper-based that could be digital - want to convert to digital later; and some cases where people will only want digital later

Action Items

1. Draft updated definition of pass and credentials and get consensus before next group meeting (Friday 4/9)
2. Raise Q of whether GHP put forward recommendations or requirements to SteerCo