Re: VC-EDU Interoperability Plug Fest and image display?

This is true.

One thing to keep in mind is that in Open Badges, the “achievement” image is typically (but doesn’t need to be) a generic image used for all earners of that credential so that the link to the image isn’t related to anyone specifically, just a generic image. But this may not be true and we should keep this in mind in our discussions about display. 

> On May 26, 2022, at 3:04 PM, David Chadwick <d.w.chadwick@truetrust.co.uk> wrote:
> 
> 
> 
> On 26/05/2022 19:30, Charles E. Lehner wrote:
>> Hi VC-EDU,
>> 
>> (Previous thread participants Bcc'd)
>> 
>> Isn't dereferencing of URLs from credentials a privacy/tracking issue? 
> Good point. Issuers already know who their users are, and if the wallet downloads the image and caches it when the VC is first installed in the wallet, then the issuer learns nothing new. However if the verifier downloads the image when it receives the VP, then yes, the URL can be used to track who the user is sending their VC to. Its a type of calling home. So should be avoided.
> 
> Kind regards
> 
> David
> 
>> Issuers could track holders by using unique image URLs in the credentials. HTML emails have a similar issue; for this reason mail clients might not load remote images by default, e.g. Thunderbird: https://support.mozilla.org/en-US/kb/remote-content-in-messages <https://support.mozilla.org/en-US/kb/remote-content-in-messages>
>> 
>> Credential refresh services could address update-ability?
>> 
>> Regards,
>> Charles E. Lehner
>> 
>> On Thu, 26 May 2022 10:16:03 -0400
>> Manu Sporny <msporny@digitalbazaar.com> <mailto:msporny@digitalbazaar.com> wrote:
>> 
>>> David Chadwick wrote:
>>>> I have a question about the display of the badge image. In the JSON
>>>> example, the image property is not actually an image, but is a URL
>>>> ("image":
>>>> "https://w3c-ccg.github.io/vc-ed/plugfest-1-2022/images/JFF_LogoLockup.png" <https://w3c-ccg.github.io/vc-ed/plugfest-1-2022/images/JFF_LogoLockup.png>)
>>>> which could point to anything.
>>>> 
>>>> There are several possible alternatives that I would like to run
>>>> past you and the group to get some feedback:
>>>> 
>>>> 1. The wallet displays the URL to the user, and allows the user to
>>>> click on it, which opens the browser, and the browser displays the
>>>> contents of the URL (whatever it contains)
>>>> 
>>>> 2. The wallet never displays the URL to the user, but automatically
>>>> dereferences the URL and displays the remote contents to the user
>>>> inside the wallet
>>>> 
>>>> 3. The issuer replaces the contents of the URL with a base64
>>>> encoded image, so that the image is embedded inside the VC (and
>>>> therefore signed for integrity)
>>>> 
>>>> Which option did you have in mind?
>>> On 5/25/22 8:49 AM, Julien Fraichot wrote:
>>>> I don’t think there is a better solution between the 2, it’s really
>>>> about trade-offs: size vs centralization.
>>> Agree with much of what Julien is saying... I'll note that there is
>>> another trade-off -- update-ability. Sometimes the issuer does want
>>> to update the image in place (new branding, new brand guidelines,
>>> etc.) for very long-lived credentials.
>>> 
>>> Universities stay around for more than a few years at a time, and
>>> your degree is typically good for a lifetime. Universities also go
>>> through (very expensive) re-branding exercises every few years... I
>>> know our local university spends millions doing this... tears down
>>> all their signs and replaces them with (questionably) improved
>>> designs every 5-10 years. The same is true for their digital assets,
>>> like brand images, paper certificates, etc.
>>> 
>>> All this to say... there is at least size vs. centralization vs.
>>> update-ability. I don't think there is a one-size-fits-all solution.
>>> 
>>> There's a lot to unpack here, and my suggestion is that we don't do
>>> that before the JFF June 6th date. :)
>>> 
>>> Can we just "do whatever our wallets do today to display images"? So,
>>> there is a URL... if it's "https://..." <https://.../> we dereference the image and
>>> display it... if it's "data:image/png;base64,SGVsbG8sIFdvcm..." <data:image/png;base64,SGVsbG8sIFdvcm...> we
>>> render it directly... and if our wallet only supports one of those
>>> options, that's all we can do for now and we can try to improve it in
>>> the future?
>>> 
>>> So we leave it as an "item to be discussed" for later plugfests?
>>> 
>>> -- manu
>>> 
>>