W3C home > Mailing lists > Public > public-credentials@w3.org > August 2021

Re: Binding credentials to publicly accessible repositories

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Tue, 3 Aug 2021 21:02:20 +0000
To: "Michael Herman (Trusted Digital Web)" <mwherman@parallelspace.net>, "public-credentials@w3.org" <public-credentials@w3.org>
Message-ID: <BY5PR02MB69791EDEB2BCF63B42866E35CDF09@BY5PR02MB6979.namprd02.prod.outlook.com>
There is no mechanism in XMP nor in most standard asset formats for establishing a model for tamper evidence, such as Digital Signatures, (H)MAC, etc.

Leonard

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Date: Tuesday, August 3, 2021 at 2:49 PM
To: public-credentials@w3.org <public-credentials@w3.org>, Leonard Rosenthol <lrosenth@adobe.com>
Subject: Re: Binding credentials to publicly accessible repositories
Leonard, how do you define "native tamper-evident system"?
Get Outlook for Android<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FAAb9ysg&data=04%7C01%7Clrosenth%40adobe.com%7Ce749e7911a234cf79f8108d956af3719%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637636133862966410%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Bb3SbvLowCDYMaye0BJhC7qNi%2BvWI%2FqoIXZE7k9TrcM%3D&reserved=0>

________________________________
From: Leonard Rosenthol <lrosenth@adobe.com>
Sent: Tuesday, August 3, 2021 10:53:47 AM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>; public-credentials@w3.org <public-credentials@w3.org>
Subject: Re: Binding credentials to publicly accessible repositories


Michael, thanks for the reference to XMP…but you are probably not aware that I am the chair of ISO TC 171/SC 2/WG 12 where XMP is standardized *and* the project leader for XMP itself.   (oh, and I am also the XMP Architect internally to Adobe 😉 ).



So yes, leveraging existing open standards such as XMP is indeed a key to delivering on the promises mentioned below – but it can’t be the only solution due to it being a text-based serialization (thus not lending itself well to binary data structures) and not having a native tamper-evident system.  Additionally, while it is supported by most common asset formats, it is not supported by all.



Leonard



From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Date: Tuesday, August 3, 2021 at 10:43 AM
To: Leonard Rosenthol <lrosenth@adobe.com>, public-credentials@w3.org <public-credentials@w3.org>
Subject: Re: Binding credentials to publicly accessible repositories

Checkout https://en.wikipedia.org/wiki/Extensible_Metadata_Platform<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FExtensible_Metadata_Platform&data=04%7C01%7Clrosenth%40adobe.com%7Ce749e7911a234cf79f8108d956af3719%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637636133862976367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BRPbvhYfgE5%2BC9qXmJNxAkS6KFMfbl0MxrKNI%2FNxGEY%3D&reserved=0>



And here's a data model to consider for use in a custom XMP profile: https://youtu.be/FFv4WZ0p3aY<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2FFFv4WZ0p3aY&data=04%7C01%7Clrosenth%40adobe.com%7Ce749e7911a234cf79f8108d956af3719%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637636133862986322%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hCH8%2FP6JT2VSeDWqRxGL%2BaTIGHZuZmNhSYRxv2bZuF8%3D&reserved=0>



Get Outlook for Android<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FAAb9ysg&data=04%7C01%7Clrosenth%40adobe.com%7Ce749e7911a234cf79f8108d956af3719%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637636133862986322%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gmj7PPWoAUS7sDemsU4%2FyUY2cTF9AcKc9SH2d5vqpIY%3D&reserved=0>

________________________________

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Sent: Friday, July 30, 2021 1:25:18 PM
To: Leonard Rosenthol <lrosenth@adobe.com>; public-credentials@w3.org <public-credentials@w3.org>
Subject: RE: Binding credentials to publicly accessible repositories



So an alternate strategy to avoid embed an actual VC or otherwise try to attach a VC to an asset is to use the metadata capabilities of each of these formats to store the credential id, @context, vc type list, credentialSubject id, the individual claims (name-value pairs), and the proof elements



…vc-if-eye each format using each format’s native metadata capabilities.



From: Leonard Rosenthol <lrosenth@adobe.com>
Sent: July 30, 2021 1:03 PM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>; public-credentials@w3.org
Subject: Re: Binding credentials to publicly accessible repositories



Michael – not sure you understand the scenario here.



We aren’t building a specific system/solution for our own needs and those of our customers – we are developing an open standard that associates provenance with existing assets (eg. JPEG, PNG, MP4, PDF, etc.).  Since those are the formats that are recognized by systems (and regulatory solutions) today, it would make no sense to start wrapping them in some other format (be it JSON, XML, or whatever).  JPEG files (for example) need to work everywhere they do today – BUT contain tamper-evident provenance.



Leonard



From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Date: Friday, July 30, 2021 at 2:46 PM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, public-credentials@w3.org<mailto:public-credentials@w3.org> <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: RE: Binding credentials to publicly accessible repositories

It’s a SMOP (small matter of programming).  Once upon a time, browers weren’t capable of displaying a lot of different kinds of resources (e.g. XML).



Why not render your VCs as XML?

…or consider using server-side rendering?

…or write an in-browser renderer using WASM?



“The difficult we can do, the impossible takes us a little bit longer…” 😊



From: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Sent: July 30, 2021 12:35 PM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>; public-credentials@w3.org<mailto:public-credentials@w3.org>
Subject: Re: Binding credentials to publicly accessible repositories



Given that putting a “.vc” file on a website or in a Twitter feed of YouTube channel isn’t going have it properly displayed – that’s not an option, unfortunately, Michael.



Leonard



From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Date: Friday, July 30, 2021 at 1:05 PM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, public-credentials@w3.org<mailto:public-credentials@w3.org> <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: RE: Binding credentials to publicly accessible repositories

I suggest storing the “original version” of the artwork as a claim within a signed credential …the credential wraps the artwork like a container or a “frame”.



I believe this is much better than trying to attach a credential to the artwork.



Best regards,

Michael Herman

Far Left Self-Sovereignist



Self-Sovereign Blockchain Architect

Trusted Digital Web

Hyperonomy Digital Identity Lab

Parallelspace Corporation



[cid:image001.jpg@01D78889.515A04B0]







From: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Sent: July 30, 2021 10:31 AM
To: public-credentials@w3.org<mailto:public-credentials@w3.org>
Subject: Binding credentials to publicly accessible repositories



I realize that I might be out on the bleeding edge a bit, though not completely as I think it is very similar to what OpenBadges will face as they move to VC’s…



In the Trust Model section of the VC Data Model spec, it states that one of aspects of that model is:

The holder trusts the repository to store credentials securely, to not release them to anyone other than the holder, and to not corrupt or lose them while they are in its care.

This is certainly true when the repository in question is something like a wallet that is designed to be kept private or local (not shared).  But what happens when the repository is designed to be out in the public… such as an image or PDF with the VC embedded?





As part of the C2PA’s (https://c2pa.org<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7Ce749e7911a234cf79f8108d956af3719%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637636133862996281%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RW1xm2%2BCS6wFs3gcp1CVKfvEZ9QuEn1kdF1SxG0ER7I%3D&reserved=0>) work on establishing provenance for digital assets, we will be using VC’s as a way for persons and organizations to establish their relationships to the asset.  Specifically in this instance, we’re extending schema.org’s Person and Organization schemas, as used by their CreativeWork schema, to support referencing a VC.  This then allows the author or publisher (or any of the other roles in CW) to provide their credentials in that role, which (a) adds useful trust signal(s) to the end consumer and (b) helps establish reputation.



These VC’s (etc.) will be embedded into the assets (e.g., video, images, documents, etc.) in a tamper-evident manner, so that in addition to the individual VC’s “proof”, any attempt to change the CreativeWork relationships, etc. can also be detected.   This all works great.



However, in doing some threat modelling, we recognized that we have no protection against a malicious actor simply copying the VC from one asset and dropping it into another (and then signing the new setup), because there is nothing that binds the credential to the asset in our case.



Has anyone run into this scenario before and has some guidance to offer?  Am I doing something that I shouldn’t be doing – and if so, what does that mean for OpenBadges?



All thoughts and suggestions welcome!



Thanks,

Leonard


image001.jpg
(image/jpeg attachment: image001.jpg)

Received on Tuesday, 3 August 2021 21:02:37 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 3 August 2021 21:02:39 UTC