Re: Proof of knowledge certs

Open Badges has used a method like this for obscuring the recipient
identifier in a badge for several versions. In Open Badges 2.0, an "
IdentityHash
<https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#identityHash>"
string could be used as the identifier (note that OB 2.0 did not use the
Verifiable Credentials Data Model). OB 3.0 still uses this concept
<https://1edtech.github.io/openbadges-specification/ob_v3p0.html#identityhash>for
VC compatible claims of achievement and other learning. The experience of
proving a badge belongs to you involved registering with a wallet
("backpack") service, proving to that service control of one or more
identifiers, typically email addresses, and then importing the badge with
the hashed identifier. The backpack checks whether any of your registered
email addresses matches the hash, and then allows upload of the badge if
there is a match and the badge is otherwise valid.

Caveats:
* It is an identifier other than the @id of the credentialSubject that is
presented in this way. The @id of credentialSubject is optional. This
IdentityHash approach is not used for any other data field besides an
identifier.
* Specific support for this technique is required, or else
credential-holder connection can't be validated.
* Out of band communication of the hashed information is required through
some mechanism.
* As implemented in Open Badges, emails were case sensitive, producing
different hashes for different variations of capitalization, even if people
and email servers generally treat email addresses as case insensitive. In a
product I worked on, we implemented a clever guessing algorithm to
dynamically generate many (but not exhaustive) possible case variations of
known email addresses to test against the hash in case the user hadn't
manually registered a certain case variation. It was a bit of a pain.

It has been an interesting approach to do it this way. Pretty wide adoption
in the pre-VC OB 2.0 ecosystem across millions of issued credentials. I
have some doubts that the necessary communication on the side of the actual
credential delivery is easy to scale for interoperability. Limiting this to
one specific field that users pretty much already needed to provide to
platforms anyway made it practical enough.


*Nate Otto*
nate@ottonomy.net
Founder, Skybridge Skills
he/him/his

On Fri, Jan 20, 2023 at 8:44 AM Julien Fraichot <Julien.Fraichot@hyland.com>
wrote:

> Hi CCG Community,
>
>
>
> I have been investigating the possibility of having certificates which
> obfuscate PII data. That is, instead of using selective disclosure schemes
> to present a curated certificate, have the holder prove they know what the
> data is within the certificate.
>
>
>