Re: Human readable credentials?

> Human-friendly representations are derived from the machine-friendly ones, keeping them in sync
>
That is most certainly one way to approach the problem.  But it is not the only one.  For example, I can show you how to deterministically produce a machine readable representation from a human-friendly one.


> Putting a B64 encoded block into a valid credential is not introducing a lot of new risk if the processing entity for that chunk is still software.
>
Sorry but I have to disagree with you on that one.  If one processor knows how to decode that B64 block and present it and another processor does not – which is perfectly acceptable since I can have custom contexts in my VC’s – then you have the same situation you have pointed out.


> The problem arises when there are two potentially divergent representations, and the two processing entities are disjoint. *That* is an exploitable gap.
>
That is *ONLY* an exploitable gap *IF* the two representations are physically separate from each other *AND* not signed/sealed together.  However, if the two are signed as a single entity, then you can’t modify one w/o invalidating the other, the preventing any form of exploit.


Leonard

From: Daniel Hardman <daniel.hardman@evernym.com>
Reply-To: "daniel.hardman@evernym.com" <daniel.hardman@evernym.com>
Date: Monday, June 8, 2020 at 3:52 PM
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: Wayne Chang <wyc@fastmail.fm>, W3C Credentials CG <public-credentials@w3.org>
Subject: Re: Human readable credentials?

>someone could just as easily do that by putting a B64 encoded block into a valid credential using a known schema

I feel like this misses the point. What I'm concerned about is introducing a different audience, not introducing a new data stream. VCs as designed today are intended to be processed by software, not humans. Human-friendly representations are derived from the machine-friendly ones, keeping them in sync. Putting a B64 encoded block into a valid credential is not introducing a lot of new risk if the processing entity for that chunk is still software. The problem arises when there are two potentially divergent representations, and the two processing entities are disjoint. *That* is an exploitable gap.

On Mon, Jun 8, 2020 at 12:54 PM Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:
You are correct, Daniel, that one potential concern is detachment of the machine readable content from the human readable content.  That, however, can be solved by choosing technology (eg. PDF) that enables bindings at the content & semantic levels, if that is indeed a requirement (for some or all use cases).

While I get where you are going with your example, someone could just as easily do that by putting a B64 encoded block into a valid credential using a known schema…but when decoded the B64 block is a text statement about what you mention.  As long as you support an open grammar (which VC does), which includes arbitrary content, you can’t avoid this problem.   The human vs. machine issue isn’t really at play on this one.

Leonard

From: Daniel Hardman <daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>>
Reply-To: "daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>" <daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>>
Date: Monday, June 8, 2020 at 2:24 PM
To: Wayne Chang <wyc@fastmail.fm<mailto:wyc@fastmail.fm>>
Cc: W3C Credentials CG <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: Human readable credentials?
Resent-From: <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Resent-Date: Monday, June 8, 2020 at 2:24 PM

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<mailto: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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fidentity.foundation%2Fcredential-manifest&data=02%7C01%7Clrosenth%40adobe.com%7C5f86fa4adcd4414c61de08d80be57dc9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637272427574316241&sdata=FOSMh0edkA3FUwtYawf5isDuh5ZiKDuBANsbJLX2Pgo%3D&reserved=0>

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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexample.org%2Fexamples%2Fdegree.json&data=02%7C01%7Clrosenth%40adobe.com%7C5f86fa4adcd4414c61de08d80be57dc9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637272427574316241&sdata=3ECCkShyhP0tbXjHxEXSSxHCCvEmxJn9%2FGLpN6WsqEc%3D&reserved=0>",
   "type": "JsonSchemaValidator2018",
   "display": "https://example.org/examples/degree.display.json<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexample.org%2Fexamples%2Fdegree.display.json&data=02%7C01%7Clrosenth%40adobe.com%7C5f86fa4adcd4414c61de08d80be57dc9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637272427574326237&sdata=3ETRnbQ79X%2Fo2qtgX88YY7FdIU9K6CmV8OxcZCaHShw%3D&reserved=0>"
 },

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.
>
>