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

Time	Item	Who
2 min	Welcome & Antitrust Policy Notice	Rebecca & Tony
25 min	Consensus Points	David Janes
35 min	Definition of Credentials v. Passes	Tony, Drummond, Marie + All
1 min	Wrap Up	Chair

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

Consensus needed: our primary goal should be to answer the KIQs.

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)

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:

we are encoding credentials defined by GHP [KIQ2, also affects KIQ6]
we are using trust frameworks defined by GHP
we are using digital signature methods defined by GHP [KIQ3]
we are using identity binding methods defined by GHP
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?
- 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 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
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

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

Browser not supported