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

Forgive me if speaking out of turn or misunderstanding, but doesn't json
already suffice for this, e.g. Google's service account JSON format for
service keys:
https://cloud.google.com/iam/docs/creating-managing-service-account-keys

I recently did a tour of various cloud vendors and for the most part it
seemed vendors supported both p12 and json

Granted I didn't check if there was any specification to how these keys are
formatted

On Sun, Jan 31, 2021 at 5:49 PM Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

> p.p.s. A single file data vault or identity hub
>
>
>
> *From:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Sent:* January 31, 2021 6:45 PM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>;
> Leonard Rosenthol <lrosenth@adobe.com>; Credentials Community Group <
> public-credentials@w3.org>
> *Subject:* RE: File formats for the secure export/import of Verified
> Credentials?
>
>
>
> RE: And would you want `application/json` or something specific to VC?
>
>
>
> Better than that, I want a secure, likely encrypted, likely
> password-protected (or some such) file format (conceptually similar
> PKCS12).  That particular format (whatever it turns out to be) will
> have/need its own file suffix and content type.  It won’t be pure JSON or
> pure VC, for that matter.
>
>
>
> *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
>
>
>
>
>

Received on Monday, 1 February 2021 02:28:34 UTC