search

hyperledger / indy-node

The server portion of a distributed ledger purpose-built for decentralized identity.
https://wiki.hyperledger.org/display/indy
Apache License 2.0
683 stars 655 forks source link

Storing person photo into Verifiable Credential #1767

Closed esrefatak closed 2 years ago

esrefatak commented 2 years ago

I'm not sure whether this place is correct but I could not find another place to ask. Sorry if it's not correct...

As you know, in traditional world, when you show your ID card to an officier, in most cases, he compares the photo with your face first. If it matched then he lets you pass.

Because of this tend, I consider to store user's photo into an attribute in verifiable credential. So that, officier can quickly check the face and verifiable credential. Does it make sense? When I have a look at use cases, did not see any implementation that stores person photo into credential.

Do you have any idea what is the reason?

dhh1128 commented 2 years ago

As to the location for this question, I think this isn't an ideal place to ask, but none of the other places I can think of are great, either. Perhaps an email to the W3C Credentials Community Group mailing list? But I predict they won't have crisp answers, either.

Regarding the question itself: Theoretically, there is nothing that prevents you, today, from including a photo in a credential. Just create a field in the schema that holds a base64-encoded dump of the .jpg, and let your verifiers know that they must require the field to be disclosed, and then interpret its bytes correctly, and it will work.

However, there are serveral reasons why this is not common practice, and why the solution you actually want is different:

  1. Photos are big. A verifiable credential without a photo might be a few KB; with it, it might be half a MB. This changes the time it takes to do an issuance and a presentation over the wire. It makes it impossible to show the credential in a QR code and may break various assumptions in the stack.

  2. When you disclose a photo, you are sharing a perfect correlator, so there's a privacy problem. Basically you've undermined anoncreds features.

Regarding the first problem, the workaround I've seen several teams do is to place in the credential just a hash of the JPEG, and then disclose the hash, along with a link to a place where the photo can be downloaded. Alternatively, DIDComm also allows you to attach arbitrary items to a credential presentation, so you can attach the jpeg but keep it outside the credential. That at least allows the credential to be small when revealing the photo isn't required.

But this still doesn't solve the second problem.

I am aware of an excellent solution to the second problem, but I can't say more about it due to intellectual property constraints. Sorry that I can't be more forthcoming.

esrefatak commented 2 years ago

@dhh1128 Thank you for your detailed answer. I understand the situation very well.