RE: File formats for the secure export/import of Verified Credentials?

Wayne, your comments suggested to me the following inspirations/possibilities:


  1.  As email attachments, .vcard files can be used for sending and receiving verifiable documents of all sorts; more specifically, as examples, meeting requests and contact information. See the attached mocked up attachments (copies of the vc_example.vcred file).  This conversation is timely as I figure out the next steps: the key infrastructure.  A .vcred uses symmetric encryption for the payload.  The symmetric encryption key is encrypted using asymmetric encryption and is also part of the .vcred.  A different set of asymmetric key pairs are generated for every file for the time being. The intent is to password encrypt these key pairs somehow and include them as part of the payload – given there is no universal, free KMS solution available.


  1.  The ballot scenario you’ve propositioned is interesting. The solution concept I have in mind is a Verifiable Cart or .vcart file – i.e. a shopping cart, wagon, or egg carton of 1 or more .vcred files.  A mock-up is also attached.  A .vcart would be a JSON wrapper for one or more .vcart files contained with it.  In the USA 2024 Election scenario, there would be a .vcred (credential) file for each ballet for “each election down the ticket”: presidential election, state elections, and local elections (as you propositioned).
You also talked about “selective disclosure” of some attributes …i.e. selected attributes that would be available to be viewed in plain text. I don’t see this use case directly asserting specific requirements on the .vcart/.vcred encrypted storage functionality. However, it needs to be accommodated.  In general, for selective disclosure, there are already existing VC-based solutions like Presentations available. So how about allowing Presentations to ride alongside the .vcred’s in the .vcart file …unencrypted so that Presentations of the attributes in the VCs encoded in the .vcred’s in the .vcart can be viewed without any decryption.
Further, to secure the contents of all the .vcred’s in the .vcart file (encrypted as well as unencrypted), each .vcred would be wrapped with some addition metadata (e.g. a payload hash) which would include the .vcred payload hash from the previous .vcred in the .vcart …in essence, creating a simple, short blockchain of .vcred’s inside the .vcart. The chain would end with a trailing encrypted .vcred that would securely anchor the chain of .vcred’s.

p.s. How is a .vcart different from a wallet? …a wallet is a piece of software …an app for securely storing credentials (and related functionality).  A .vcart is standalone standardized file format for securely storing credentials.

More news at 11…
Michael Herman
Self-Sovereign Blockchain Architect
Trusted Digital Web
Hyperonomy Digital Identity Lab
Parallelspace Corporation

[cid:image007.jpg@01D6FA0B.E3CC9C70]



From: Wayne Chang <wyc@fastmail.fm>
Sent: February 2, 2021 8:27 PM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>; Leonard Rosenthol <lrosenth@adobe.com>; W3C Credentials CG <public-credentials@w3.org>
Subject: Re: File formats for the secure export/import of Verified Credentials?

Of interest to some folks may be the ability to partially protect some fields while allowing other fields to stay plaintext or protected differently. This could give wallets and humans a sense of what may be inside.

For example, imagine receiving a VC of a ballot for voting, indicating which district and election for a ballot handler, with the actual candidate selection cryptographically protected in a way that's only usable by the ballot counter using decryption or ZKP tallying.

I can think of a few ways to do this with JSON-LD and XMLDSig, but some may object to adding a dependency on these technologies.

On Tue, Feb 2, 2021, at 12:57 PM, Michael Herman (Trusted Digital Web) wrote:

Leonard, I have a prototype .vcred archive/export/import file format working.



It’s typed and versioned, binary (not JSON but could be wrapped in a JSON envelope), RSA encrypted file format. I also have a prototype tool Acme VCredReader Workbench for playing around with them.  The test data is: https://www.w3.org/TR/vc-data-model/#example-1-a-simple-example-of-a-verifiable-credential (but it doesn’t really matter what it is.)



Here are a few screenshots.



[cid:image002.jpg@01D6F9FC.E7BB3990]



[cid:image003.jpg@01D6F9FC.E7BB3990]





From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Sent: January 31, 2021 6:26 PM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>; Credentials Community Group <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: RE: File formats for the secure export/import of Verified Credentials?



These are good questions but it wasn’t where I was coming from originally (but read through to the end of this email for some separate but related activity).



More specifically,  I was thinking of something like the https://en.wikipedia.org/wiki/PKCS_12 file format <https://en.wikipedia.org/wiki/PKCS_12%20file%20format%20for%20X.50s>  for X.509 certs where you can export and secure it with a password, etc. …possibly include key pairs, etc.  I’m at the 10,000 level on this …actually only at about 1045 meters (elevation of Calgary ASL).



Here’s a scenario:



The scenario is Alice User bootstrapping/onboarding herself into an app with a copy of her personal "Member" or "Citizen" VC …onboarding Alice into her local instance of the mobile or desktop app.



The attributes would only be shared within the app on a traditional SSI selective disclosure basis ...so it is the very initial use case where you're claiming an instance of a mobile or desktop as "your own" ...an identity bootstrapping/onboarding process.  (The app is sort of wallet/agent but is also capable of hosting any number of pluggable applets.)



...where you're not beholding to any issuer or service provider once the credential has been issued and persisted into a file (modulo downstream VC verification). You can take your secure “vcred” file and present it to any app you want to onboard into it. It’s related to the SSI Personal Data Usage License problem I wrote about here: https://docs.google.com/document/d/1yP0OgDhq-3TTIien5gsETi4jZdyiKbwE/edit. ….now I’m building it out.



----

Footnote: Leonard, that being said, today, I was fooling around with my Windows 10 laptop to imagine what a fully integrated Windows shell experience might look like for these file types.  I chose .vcred as the File Suffix and application/vcred as the Content Type.  I’ve attached a safe copy of the Windows Regedit script if you’re interested. (You will need to tweak the file system location of the .ico icon file.)  I don’t know if or how Windows uses the Content Type but I have all of the file suffix stuff working (notepad.exe is my dummy Acme VCredReader app).  Here’s a screenshot.



NOTE: This is not the point of my original question …but a parallel line of thinking.  Thank you for the question.



[cid:image004.jpg@01D6F9FC.E7BB3990]



From: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Sent: January 31, 2021 4:29 PM
To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>; Credentials Community Group <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: File formats for the secure export/import of Verified Credentials?



Michael – forgetting about the file name extensions (which is the part of the article that you linked to) what actual format(s) are you thinking of using and what associated media type?



Aren’t the majority (all?) of the VC’s going to be in JSON?   And would you want `application/json` or something specific to VC?



Leonard



From: "Michael Herman (Trusted Digital Web)" <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Date: Sunday, January 31, 2021 at 2:26 PM
To: Credentials Community Group <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: File formats for the secure export/import of Verified Credentials?
Resent-From: <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Resent-Date: Sunday, January 31, 2021 at 2:24 PM



Hopefully, it’s not sacrilege to suggest something like this might be useful: File formats for the secure export/import of Verified Credentials?



…something like the file formats used for exporting/importing X.509 certificates (https://en.wikipedia.org/wiki/X.509#Certificate_filename_extensions<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FX.509%23Certificate_filename_extensions&data=04%7C01%7Clrosenth%40adobe.com%7C0af54d6f44114b01a10008d8c61e19c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637477179879803301%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=l1g%2FNveQYKQS7MDKDtAgsG0OAx5OF6OMLQJC0dxW0e4%3D&reserved=0>).



Best regards,

Michael Herman

Self-Sovereign Blockchain Architect

Trusted Digital Web

Hyperonomy Digital Identity Lab

Parallelspace Corporation



[cid:image008.jpg@01D6FA0B.E3CC9C70]



Attachments:

  *   image001.jpg
  *   image004.jpg
  *   image005.jpg
  *   image006.jpg