[To Discuss] Image integrity
kimdhamilton opened this issue · comments
Image/display discoverability and generalization
(Source: Anthony Camilleri) We might consider adding a 'displayproperties' field into the credential. This could include html defining the look and feel of the credential, allowing export to pdf/xml/image/openbadge or any other format we need printing. Several countries define the visual look of credentials by law, so this would give us full coverage of both systems. This would allow for a pdf VC wrapper to be generated from the VC itself.
Problems to address
I've identified two problems we're trying to address. Given that there are two different problems, we may want to split this issue after elaboration.
- Verification of visual integrity of VC for human verifiers
- Metadata indicating visual representation for different purposes.
- different form factors
- "preview" display
- grouping, e.g. show issuer's logo in a wallet grouping
Methods
Methods to connect a VC to its visual representation in a tamper-evident way are discussed elsewhere (e.g. "Verifiable Displays")
- embed image, html, ...
- link (with hash), e.g. hashlinks
- templates -- fixed/known templates, link to template in credential, etc
- similar: designate certain "core" fields for a credential card view
But that largely focuses on problem 1 above. It is worth exploring the conceptual match we are getting at with problem 1 -- are we talking about a more general category of verification instructions? I.e.
- Verification instructions
- machine
- human
- ???
Design considerations
In general, issuers want control over the visual representation and there's no strong reason (at the moment) to constrain choices among the methods discussed above.
At the same time, to support interoperability among tools and apps, we may prefer some standardization of certain image (or other) related metadata, e.g. preview images, issuer logos, whether generally, per-domain, etc.
Other relevant considerations:
- Flexibility
- Size
- Availability; minimizing external dependencies
Design Inspiration
Regarding problem 2, some relevant patterns include:
- Apple wallet developer guidance. Some interesting links
- Styles (similar to what I call templates)
- pass package highlights:
- https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/PassKit_PG/YourFirst.html
- These commands create a signed and compressed pass named Lollipop.pkpass in the Documents folder. If the signpass command fails, make sure you are using your correct pass type identifier and check that the pass.json file contains valid JSON
- Design of a "pass"
- Add to wallet guidelines
- Back of the pass (similar to "card")
- Epub spec
Where does this live?
Some of these concerns are general and some are specific to EDU. This needs to be broken down.
Related to #16 Credential Display Logic