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.

>  

> 

>  

> 

>  

>  

> *From:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net> 
> *Sent:* January 31, 2021 6:26 PM
> *To:* Leonard Rosenthol <lrosenth@adobe.com>; Credentials Community Group <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.

>  

> 

>  

> *From:* Leonard Rosenthol <lrosenth@adobe.com> 
> *Sent:* January 31, 2021 4:29 PM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>; Credentials Community Group <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>
> *Date: *Sunday, January 31, 2021 at 2:26 PM
> *To: *Credentials Community Group <public-credentials@w3.org>
> *Subject: *File formats for the secure export/import of Verified Credentials?
> *Resent-From: *<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

>  

> 

>  

> 
> *Attachments:*
>  * image001.jpg
>  * image004.jpg
>  * image005.jpg
>  * image006.jpg