Re: Human readable credentials?

The challenge with a "here's how to display this" construct embedded in a
credential is that it may not align perfectly with the data -- and that
creates a gap that could be problematic.

An exaggerated example of this problem might be: a malicious issuer could
produce a diploma that certifies that Alice graduated, and include a PNG of
the diploma that looks beautiful -- but include a field in the JSON that's
hidden in the human-friendly display, saying that Alice was a terrible
student and should never be hired or treated like a college graduate. Alice
then shares her credential not realizing that it's damaging her
reputation, since what she sees when she inspects it looks great. This
particular abuse case is pretty unlikely, and it's disincentivized by the
hit to issuer reputation that would eventually unfold. However, subtler
problems with gaps are more believable. For example, an image-based display
of the credential eliminates the possibility of translating the field names
into the locale of the verifier. It also makes the credential incompatible
with the overlay technology that Paul Knowles and others have championed.
And it makes selective disclosure problematic. Etc.

That doesn't mean the idea is unworkable -- just that it has some
subtleties to sort through.

On Mon, Jun 8, 2020 at 11:46 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.
> >
> >
>
>