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>
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>
> *Reply-To: *"daniel.hardman@evernym.com" <daniel.hardman@evernym.com>
> *Date: *Monday, June 8, 2020 at 2:24 PM
> *To: *Wayne Chang <wyc@fastmail.fm>
> *Cc: *W3C Credentials CG <public-credentials@w3.org>
> *Subject: *Re: Human readable credentials?
> *Resent-From: *<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> 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%7Ceff539652038454b781408d80bd92ba3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637272374673869861&sdata=Wa1%2BgAjas7nIl6yroqJVwkC3jgx6q%2Bgt0Xj4gRoNCrc%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%7Ceff539652038454b781408d80bd92ba3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637272374673869861&sdata=PoEdI55w86sxGfV9iHlvbxG4xXDf1XncaAROM0QV4Lk%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%7Ceff539652038454b781408d80bd92ba3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637272374673879856&sdata=4g009pcFYOgwnq1gY8TJxrSML7GF8d4XFh%2BD2Up8RlA%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.
> >
> >
>
>