Stream: smart/health-cards
Topic: Issuer metadata in VCI Directory
JP Pollak (Jan 25 2022 at 15:41):
hi all. @Reece Adamson recently added broader metadata support to the VCI Directory and we intend to begin filling that out.
today i’m looking at issuer_type. this could be useful for those of us making consumer facing tools and some verifiers are likely to be interested in what type of entity has issued an SHC. would love some quick feedback before we go with this and start populating.
here is the starting point for the value set that may expand over time, ie don’t worry if you feel it’s incomplete unless you think there are current or soon-to-be issuers who do not fit:
nationstate_province_territorycityhealth_systeminsurerlaboratorypharmacy
question for the channel. if you would make use of these data, would you rather it be (1) flat as above or (2) include some baked in hierarchy for filtering on entity types like governments and organizations? eg:
governmental.nationgovernmental.state_province_territorygovernmental.cityorganizational.health_systemorganizational.insurerorganizational.laboratoryorganizational.pharmacy
feel free to vote
- :one: for flat
- :two: for hierarchical
or weigh in if this is off, could be improved, or otherwise. thanks!
Vitor Pamplona (Jan 25 2022 at 15:55):
These should also be verifiable credentials signed by the issuer, same key used on the QRs.
Vitor Pamplona (Jan 25 2022 at 15:57):
Otherwise, there is still too much trust on the system.
Josh Mandel (Jan 25 2022 at 15:59):
To be clear, these assertions are being made by VCI directory, not by the issuers
Josh Mandel (Jan 25 2022 at 15:59):
So I don't understand how it makes sense for them to be signed by the issuer keys.
Josh Mandel (Jan 25 2022 at 16:00):
We do have a separate discussion about how issueres can published additional metadata, but I would suggest we leave that out of scope for this thread, so we can have a scoped discussion about the codes/hierarchy here. Might start a separate thread for discussion about publication patterns beyond a simple directory.
Vitor Pamplona (Jan 25 2022 at 16:02):
When issuers register to insert the data, that data should be signed as well. Otherwise, it is quite meaningless for verifiers since we can't figure out if the person applying for the VCI directory is the same as the one issuing credentials.
Vitor Pamplona (Jan 25 2022 at 16:03):
Basically, I am asking for a proof of keys for each entry on the registry.
Josh Mandel (Jan 25 2022 at 16:04):
VCI directory process/policies are at https://github.com/the-commons-project/vci-directory - feel free to raise issues if there are specific concerns (but to be clear, this model absolutely places trust in the directory and its operators; we have not tried to avoid that in the current process)
Vitor Pamplona (Jan 25 2022 at 16:05):
I know. And that sucks. There are options to avoid that trust
Josh Mandel (Jan 25 2022 at 16:06):
Agreed there is more that can be done; all a question of priority
Vitor Pamplona (Jan 25 2022 at 16:08):
Sure. But since people are defining the payload now, it's going to be a lot easier to do it right than having to significantly change it later.
Vitor Pamplona (Jan 25 2022 at 16:12):
And since the EU Gateway, the WHO Registry and the Linux Foundation GCCN networks are all going into that direction, you might as well get ready for it now.
Vitor Pamplona (Jan 25 2022 at 16:20):
For the payload structure, I would also suggest taking a hard look at groups whose sole career is to design schemas for Trust Registries, like the ESSIF-TRAIN lab at the Fraunhofer Institute: https://gitlab.grnet.gr/essif-lab/infrastructure/fraunhofer/train_project_summary
Vitor Pamplona (Jan 25 2022 at 16:40):
On top of that, making this metadata a verifiable credential kills all the constant criticism of requesting everyone to use verifiable credentials but not using it ourselves (among people defining verifiable credentials). The registry needs to be a verifier and an issuer at the same time. Let's lead by example. "Do as I do" is a lot more compelling than "Do as I say".
Nathan Bunker (Jan 25 2022 at 21:52):
The hierarchical looks best to me, but flat would probably work fine too.
This will be very helpful to Immunization Information Systems (registries). Which, in the US are mostly 'governmental.state_province_territory' and a couple 'governmental.city'. We used to have IIS who operated at the county level, but I think the last one that might have issued SHC's is merging with their state system that already supports SHCs. So these categories should work for the US.
Last updated: Apr 12 2022 at 19:14 UTC
