Re: Video: Using Paper-based Structured Credentials to Humanize Verifiable Credentials

So you are looking at this from the app side – and you are right, in the Windows world the applications make calls to the printing system which in turns pass them to the printer driver.   On the Mac and on Linux, you pass a PDF to printing subsystem.

What I was referring to was how that same printer driver then communicates to the printer itself – and that is (predominately) either by sending a PDF or by sending raster.   (of course there are exceptions, where Postscript, PCL or other old-school print description languages are sent – but those aren’t the norm).

And that is what happens in “desktop printing” – it is not the same as what takes place in the commercial or production printing world – or any of the specialized printing environments like packaging, vehicles, label, etc.  One of the key additions to those worlds is the existence of a DFE (Digital Front End) which serves as “front end” (as the name implies) between the physical output device and the systems providing input.  In that regard, it is similar to what you are describing below in assumption #4 as an “Agent Service Endpoint” – though they, of course, don’t do VC’s.   Some of them, however, do introduce aspects of what that industry refers to as “Secure Printing” which combines access control with tracking/analytics.

To your solution, the idea of using MACs for a DID for a device is interesting and I could see a variety of possible uses for it – providing you can figure out how to build a scalable solution of registry and mapping to a service endpoint.

Leonard

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Date: Friday, November 19, 2021 at 8:47 PM
To: Leonard Rosenthol <lrosenth@adobe.com>, public-credentials@w3.org <public-credentials@w3.org>, Leah Houston, MD <leah@hpec.io>, chris_raczkowski@hotmail.com <chris_raczkowski@hotmail.com>
Subject: RE: Video: Using Paper-based Structured Credentials to Humanize Verifiable Credentials
RE: As most printers today either take PDF files as input (either directly or wrapped in “special sauce”) or take raster images - you’d actually end up with a better solution for the problem by embedding the VC into the PDF or image (as I have talked about in the past) an sending that, instead of the other way around.

From an end-user perspective, it may appear that printers accept PDF files and/or raster images but they actually don’t (at least not in the Microsoft Windows printer device driver world).

The app (e.g. Adobe Reader, Microsoft Word, Microsoft Paint, etc.) processes the app’s supported/native file format and then calls a set of lower-level Windows printer APIs (e.g. https://docs.microsoft.com/en-us/windows/win32/printdocs/printdocs-printing<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fprintdocs%2Fprintdocs-printing&data=04%7C01%7Clrosenth%40adobe.com%7C97afadd1a5264e27db3008d9abc77346%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637729696580700830%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=c%2BnEJubvzv8qKy35N6OY5Z8reagYTg6VdXiVfz%2FLgWE%3D&reserved=0>) which in turn get translated into printer codes that are specific to each manufacturer’s family of printers (e.g. PostScript, HP print code).

But I diverge … the answer I had in mind looks something like this:

Assumptions


  1.  Each (networked) printer’s network has an Ethernet physical MAC address (e.g. 30-3A-64-8B-70-40)
  2.  Assign to each (networked) printer a DID based on its MAC address: DID:TDW:MAC: 30-3A-64-8B-70-40
  3.  Ensure each of these printer MAC DIDs has a resolvable DID Document
  4.  Ensure each MAC DID resolvable DID Document has an Agent Service Endpoint that accepts (spools) a VC-encapsulated print code stream and can spool (stream) the print code stream to the printer with a network card that has a matching MAC address

Process


  1.  Discover the MAC DID for the target printer (or otherwise create a list of MAC DIDs for all the printers on the planet).
  2.  Retrieve the DID Document for each MAC DID
  3.  Retrieve the Agent Service Endpoint from each DID Document
  4.  Stream the VC-encapsulated print code stream to the Agent Service Endpoint
  5.  Optionally, repeat for every MAC DID on the planet.

Voila.  You read it here first 😉 😊

Best regards,
Michael Herman

From: Leonard Rosenthol <lrosenth@adobe.com>
Sent: November 19, 2021 7:59 AM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>; public-credentials@w3.org; Leah Houston, MD <leah@hpec.io>; chris_raczkowski@hotmail.com
Subject: Re: Video: Using Paper-based Structured Credentials to Humanize Verifiable Credentials

Michael – it’s an interesting question, but it is also too wide open and doesn’t take into account how printing works either for the average consumer or in the professional printing world.

As most printers today either take PDF files as input (either directly or wrapped in “special sauce”) or take raster images - you’d actually end up with a better solution for the problem by embedding the VC into the PDF or image (as I have talked about in the past) an sending that, instead of the other way around.  Then you’d want to integrate the VC-validation component into the printer.

That said, I am not sure that I understand the use case here beyond a “modernization” of existing enterprise-level printer security or analytics/tracking systems.

Leonard

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Date: Friday, November 19, 2021 at 8:59 AM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>, public-credentials@w3.org<mailto:public-credentials@w3.org> <public-credentials@w3.org<mailto:public-credentials@w3.org>>, Leah Houston, MD <leah@hpec.io<mailto:leah@hpec.io>>, chris_raczkowski@hotmail.com<mailto:chris_raczkowski@hotmail.com> <chris_raczkowski@hotmail.com<mailto:chris_raczkowski@hotmail.com>>, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Subject: RE: Video: Using Paper-based Structured Credentials to Humanize Verifiable Credentials
Pop Quiz: If VCs are used to encapsulate PostScript or HP print code printer jobs, how can these VC-encapsulated print jobs be printed on any (or every 😉) printer on the planet?

Prize for first and simplest solution: Free drink in NYC Nov. 24-Dec. 2, 2021.  …not every day 😉

Best wishes,
Michael

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Sent: November 18, 2021 8:04 PM
To: public-credentials@w3.org<mailto:public-credentials@w3.org>; Leah Houston, MD <leah@hpec.io<mailto:leah@hpec.io>>; chris_raczkowski@hotmail.com<mailto:chris_raczkowski@hotmail.com>; Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Subject: Video: Using Paper-based Structured Credentials to Humanize Verifiable Credentials

Leah, Chris, and co.,

Here’s an interesting follow-on tutorial to the previous Structured Credential video. This one is entitled:

Using Paper-based Structured Credentials to Humanize Verifiable Credentials (9 minutes)
https://www.youtube.com/watch?v=kM30pd3w8qE&list=PLU-rWqHm5p45dzXF2LJZjuNVJrOUR6DaD&index=1<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DkM30pd3w8qE%26list%3DPLU-rWqHm5p45dzXF2LJZjuNVJrOUR6DaD%26index%3D1&data=04%7C01%7Clrosenth%40adobe.com%7C97afadd1a5264e27db3008d9abc77346%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637729696580700830%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6B5HOuTmmj2PxeNtKJSjMWi5pTEQESeI%2FiVX0qHnK8Y%3D&reserved=0>

This tutorial was inspired by a recent (November 2021) conversation with Chris Raczkowski.  At the end of the video, I briefly discuss the Structured Credential Economic Model and hint about how SCreds can be used to represent NFTs.

The link to the previous Structured Credential video (if you need more background): https://www.youtube.com/watch?v=9RLYS7Xvabc&list=PLU-rWqHm5p45dzXF2LJZjuNVJrOUR6DaD&index=2<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D9RLYS7Xvabc%26list%3DPLU-rWqHm5p45dzXF2LJZjuNVJrOUR6DaD%26index%3D2&data=04%7C01%7Clrosenth%40adobe.com%7C97afadd1a5264e27db3008d9abc77346%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637729696580710789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mOWqRby01%2FEZcwQxwgLa42SML%2BePfpjANX0PDj%2BJIf8%3D&reserved=0> .

[cid:image001.jpg@01D7DF77.44C0D770]

Best regards,
Michael Herman
Far Left Self-Sovereignist
First Principles Thinker

Self-Sovereign Blockchain Architect
Trusted Digital Web
Hyperonomy Digital Identity Lab
Parallelspace Corporation

[cid:image002.jpg@01D7DF77.44C0D770]



From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Sent: August 25, 2021 3:46 AM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>; Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>; public-credentials@w3.org<mailto:public-credentials@w3.org>
Subject: RE: VC-if-eye a plain old .JPG file [was: Binding credentials to publicly accessible repositories]

Here is a link to my latest tutorial on Structured Credentials: https://www.youtube.com/watch?v=KVyITrA5glM&list=PLU-rWqHm5p45dzXF2LJZjuNVJrOUR6DaD&index=1<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DKVyITrA5glM%26list%3DPLU-rWqHm5p45dzXF2LJZjuNVJrOUR6DaD%26index%3D1&data=04%7C01%7Clrosenth%40adobe.com%7C97afadd1a5264e27db3008d9abc77346%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637729696580710789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5EK2MEhtJ4Bgm3hlixQekLrxypri%2Fbk1N6nzWzsdAks%3D&reserved=0>

Where am I headed with this? Hopefully (now that I have a better understanding of the CCG Work Item process), Structured Credentials will become a W3C Note of some sort in the VC 2.0 timeframe.  Structured Credentials, today, are supported by live working code in the Trusted Digital Web project (as illustrated in the video).

Best regards,
Michael Herman
Far Left Self-Sovereignist
First Principles Thinker

Self-Sovereign Blockchain Architect
Trusted Digital Web
Hyperonomy Digital Identity Lab
Parallelspace Corporation

[cid:image003.jpg@01D7DF77.44C0D770]



From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Sent: August 9, 2021 7:12 AM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>; public-credentials@w3.org<mailto:public-credentials@w3.org>
Subject: RE: VC-if-eye a plain old .JPG file [was: Binding credentials to publicly accessible repositories]

The largest difference that I see in the 2 approaches is that in the baboon scenario, the VC is being embedded as an opaque blob and is not easily/more difficult to view and/or process.

Whereas in my horse bridle scenario where the Structured Credential is clearly visible and IMO more easily processible (at least on the Trusted Digital Web). I can easily affirm that the horse bridge .JPG file *is* an actual VC (or at least a clearly decernable container for an actual VC).

I believe what you’d like to capture is what we call in the seismic data processing/well logging industry as the Processing History for a media file?

This is an orthogonal concept and easy to handle.  A separate claim can be added to the Claims component of the Structured Credential that defines the operations and parameters of the immediately preceding workflow step that produced the current image.  All of the media inputs to this step by named by their DIDs (dutifully recorded on a VDR and immediately retrievable by calling upon each media inputs agent service endpoint).  There is (with this approach) no need to record and store the entire processing history with each image/media asset – only the immediately processing step’s actions and parameters.  The previous workflow steps can be recursively retrieved by going back to the VDR for each input asset and retrieving the asset (and hence, its Structured Credential elements).  This network (graph) of interconnection and interrelationships is exactly what underpins the Trusted Digital Web.

Where can we go from here?

From: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Sent: August 9, 2021 6:43 AM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>; public-credentials@w3.org<mailto:public-credentials@w3.org>
Subject: Re: VC-if-eye a plain old .JPG file [was: Binding credentials to publicly accessible repositories]

Michael – Thanks for taking the time to experiment with this.  You are (for the most part) where we were two years ago when we first started down the path towards architecting the technology behind the Content Authenticity Initiative.  Like you, we had hoped to be able to do everything with XMP and VC.  I found this old image from our original prototype that should feel familiar 😉.

[Timeline  Description automatically generated with low confidence]

While this method works, for the most part, for raster images with a single claim/credential – it immediately breaks down in pretty much any other workflow.  Whether it is the image going through normal editing & publishing flows (e.g. Camera->Photoshop->Twitter) or being used as an ingredient in a multi-image combined scenario (e.g., placing one image into another).   And when you get to other asset types – video, documents, 3D, etc. more and more problems ensue.   Which is why we ended up having to moving away from that approach.

But at the end of the day, we are still using VC’s for what they were intended to accomplish (identity and accomplishments) as part of our larger attribution system.  You can learn about it at https://contentauthenticity.org/how-it-works<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcontentauthenticity.org%2Fhow-it-works&data=04%7C01%7Clrosenth%40adobe.com%7C97afadd1a5264e27db3008d9abc77346%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637729696580720747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ePapypLFQP5AuCgs%2FD%2FEHOW%2B6rd4J3tbzQnO7kv9OUg%3D&reserved=0> and keep an eye on https://c2pa.org<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C97afadd1a5264e27db3008d9abc77346%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637729696580720747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MX9kHYK0sg80Yz%2FFY8opm40YxBSsu70WLBQZH8AT01E%3D&reserved=0> where we will be making more technical material available shortly.

Leonard

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Date: Monday, August 9, 2021 at 1:49 AM
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: VC-if-eye a plain old .JPG file [was: Binding credentials to publicly accessible repositories]
RE: 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 here’s a counterexample.

I’ve applied to the principles and data model for Structured Credentials (https://www.youtube.com/watch?v=FFv4WZ0p3aY&list=PLU-rWqHm5p45dzXF2LJZjuNVJrOUR6DaD&index=1<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DFFv4WZ0p3aY%26list%3DPLU-rWqHm5p45dzXF2LJZjuNVJrOUR6DaD%26index%3D1&data=04%7C01%7Clrosenth%40adobe.com%7C97afadd1a5264e27db3008d9abc77346%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637729696580730690%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jgwnH1cNt0JCtUWL4SeyTnDlLtqNyud1zeO3kUxSw8I%3D&reserved=0>) to VC-if-eye a plain old .JPG file (a photo I took with my Pixel 4a phone).


  *   Test1_original.jpg is the original, unmodified test copy of the photo
  *   Test1_ps1.txt is a script that uses exiftool.exe to add the Structured Credential structures to the original test copy of the photo …including the proof elements stored in the EnvelopeSeal structure.  They are stored as elements in the XMP Keyword Info property of the photo.
  *   Test1_xmp.png is a screen shot of the Structured Credential structures embedded into the XMP Keyword Info properties of the photo.

We now have a mechanism for a .JPG file (or any XMP compatible media file) to serve as both a photo and a Verifiable Credential.  We are now able to VC-if-eye any XMP compatible media file.

Any holes?

Best regards,
Michael Herman
Far Left Self-Sovereignist

Self-Sovereign Blockchain Architect
Trusted Digital Web
Hyperonomy Digital Identity Lab
Parallelspace Corporation

[cid:image005.jpg@01D7DF77.44C0D770]



From: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Sent: August 3, 2021 3:02 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

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<mailto:mwherman@parallelspace.net>>
Date: Tuesday, August 3, 2021 at 2:49 PM
To: public-credentials@w3.org<mailto:public-credentials@w3.org> <public-credentials@w3.org<mailto:public-credentials@w3.org>>, Leonard Rosenthol <lrosenth@adobe.com<mailto: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%7C97afadd1a5264e27db3008d9abc77346%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637729696580740659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qZNh2q7DnqQ2W7jCie2Meu3dYUisqzxRxPC2%2BcWAOqw%3D&reserved=0>

________________________________
From: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Sent: Tuesday, August 3, 2021 10:53:47 AM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>; 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


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<mailto:mwherman@parallelspace.net>>
Date: Tuesday, August 3, 2021 at 10:43 AM
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

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%7C97afadd1a5264e27db3008d9abc77346%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637729696580740659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=RfN83KIxtHuDNpMKo1BYSEyckEQEHL2pBL6E6DJd%2BkM%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%7C97afadd1a5264e27db3008d9abc77346%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637729696580750607%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gDNfr2sXaZaTH6K0mXbnGs4ELvaTbOPpXUXGBlIjnK0%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%7C97afadd1a5264e27db3008d9abc77346%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637729696580750607%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4uxmolVJOMHBVN05OK2ZKqpfSkjG2Ib32dab9q4U69o%3D&reserved=0>

________________________________

From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Sent: Friday, July 30, 2021 1:25:18 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



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<mailto:lrosenth@adobe.com>>
Sent: July 30, 2021 1:03 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



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:image006.jpg@01D7DF77.44C0D770]







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%7C97afadd1a5264e27db3008d9abc77346%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637729696580760570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=snyoFNAN4afz7rp5d8nI8ARTC3%2BAwURPXpj34%2BOAavs%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