Re: Human readable credentials?

Hi Jeremy,
I’ll add that for educational credentials, we are very interested in
providing both human and machine readable representations.

Two aspects to your question:
1. How it’s done: as you mentioned, hashlinks is one way. The other is
embedding a data uri. The CCG VC-examples repo has some examples of the
latter.

 Both provide content integrity checks, which is a key characteristic.

2. Discoverability of image data for wallets, etc: we don’t yet have a
standard way to do this across different credential types. I’d be
interested in adding this considering to Orie’s wallet spec draft, which
we’re addressing on the call tomorrow.

If you can, please join the call tomorrow to discuss.

Some history: Ganesh Annan and I wrote a paper on “resource integrity
proofs” a couple years back which may need to be updated. But the
“verifiable display” notion was intended to add extra metadata, supporting
scenarios such as discoverability of multiple embedded/linked images, e.g.
if you wanted the wallet to display images for groups of credentials (by
issuer, etc)

https://nbviewer.jupyter.org/github/WebOfTrustInfo/rwot7/blob/master/final-documents/resource-integrity-proofs.pdf


On Mon, Jun 8, 2020 at 10:47 AM Wayne Chang <wyc@fastmail.fm> wrote:

> Hi Jeremy, thanks for your thoughtful message and welcome to the
> community! I think it'd be extremely valuable to have a generic way to
> introspect what's in a credential via human user interface.
>
> An important concern is that today, the types of data going into
> credentialSubject are being actively figured out through trial and error.
> Until there is obvious alignment around that (decent volume production
> deployments), the best we can do is perhaps help a non-technical user walk
> the json tree. If the credentials are using a concrete RDF syntax such as
> JSON-LD then perhaps standard display instructions can be simply associated
> with the context, and failing the presence of those instructions, it could
> fall back to a default mode.
>
> One related effort I'm aware of is called credential manifest, which has
> some style specifiers used by user agents such as wallets to display
> _requests_ for credential issuance rather than the credentials themselves:
> https://identity.foundation/credential-manifest
>
> If we want to add a field within a credential that suggests to
> human-facing UI how to interpret/display the credential, maybe a good place
> to investigate is the `credentialSchema` field which might hold an
> additional field like so:
>
>  "credentialSchema": {
>    "id": "https://example.org/examples/degree.json",
>    "type": "JsonSchemaValidator2018",
>    "display": "https://example.org/examples/degree.display.json"
>  },
>
> Maybe someone part of the SVIP cohort wants to chime in on how they mapped
> the credential to wallet display UI, and how they might handle any
> unrecognized credentials if at all?
>
> On Mon, Jun 8, 2020, at 12:44 PM, Jeremy Townson wrote:
> > I have a question for the group about displaying credentials to humans.
> Credentials, being JSON, are machine readable, okay, but when the machine
> is told to display the credential on screen, what does the machine do?
> >
> > Does this matter? It would appear so.. A holder may wish to make a
> visual check of a credential he holds. An issuer may wish their credentials
> to display their logo, etc. In fact, one can imagine it being useful to
> display virtually any credential, except possibly login credentials and
> that kind of thing.
> >
> > Since credentials have emerged from linked data on the web, one idea
> would be to continue to do what the web does generally and have a web page
> render a credential. But the integrity of that web page and of the
> credential are guaranteed in different ways. How then would the view and
> the credential be tied to the same issuer?
> >
> > It seems you could address this question in two ways. One would be to
> embed the view data into the credential itself. For example, a credential
> could contain a field like "view": "*some mime message or whatever*".
> Another would be to use a content-addressable link, such as a hashlink,
> where the content contains the same info.
> >
> > The problem here is neither of those approaches are standard in the data
> model. Seemingly, it would be useful if they were standard because an
> arbitrary wallet, given an arbitrary credential would know how to display
> it.
> >
> > So finally, my question. What ways are people using to display
> credentials, are they robust and is there any best approach that might be
> worthy enough to standardise?
> >
> > Many thanks,
> > Jeremy Townson
> >
> > ps: I've enjoyed watching the CG list file through my inbox. It seems a
> very coherent group, which hopefully gives as good a chance of success in
> this world.
> >
> > pps: To introduce myself, I have been working on a Scala implementation
> of the VC data model.
> >
> >
>
>