Ability to add images in verifiable claims

[r-soltani]

Are the any thoughts or discussions around how to embed images (ex. passport photos) in verifiable claims? Are there any recommendations of normalization methods, compression or encoding recommendations on binary/image data in VC?

[davidlehn]

One option is to add a property such as http://schema.org/image with a data URL value.

[msporny]

@r3-za what @davidlehn said. The recommended practice is to use schema.org image w/ a data URL value. That said, if you don't want multi-MB Verifiable Credentials, you should use links to images instead of embedding the images. There is also talk of using content-addressable links, like an IPFS link or named information ni:///, for example... but there is no recommended practices for that yet.

[dlongley]

That said, if you don't want multi-MB Verifiable Credentials, you should use links to images instead of embedding the images.

Keeping in mind the privacy considerations (leakage to the image server).

[r-soltani]

Thank you for the suggestions.
I agree with @dlongley that storing images on a third party server raises some privacy concerns.
And using the image property to point to a server image may not be sufficient for signature validation since the image itself may change..
The content-addressable links are an interesting idea.. having the hash of the image in the URL address ex. /ipfs/QmW2WQi7j6c7UgJTarActp7tDNikE4B2qXtFCfLPdsgaTQ/passport_photo.jpg
or
ni:///sha-256;QmW2WQi7j6c7UgJTarActp7tDNikE4B2qXtFCfLPdsgaTQ .. That way changes to the image can break the hash and the signature in VC.

[r-soltani]

Furthermore if the DOD which containts the verifiable claims contain an NI:// address then essentially the hash of a portrait photo is stored on blockchain. Isn't that a privacy concern?

[msporny]

hash of a portrait photo is stored on blockchain. Isn't that a privacy concern?

That assumes two things 1) that we are storing hashes of photos on chain, which some will choose not to do (most will store that sort of stuff off chain in a private digital wallet), and 2) that the hashes are computationally feasible to reverse.

The first item is the best way to protect yourself, the second may be infeasible even with the advent of quantum computers. Whether or not something is a privacy concern is dependent on the expected level of privacy.

[stonematt]

what's the next step on this topic?

[David-Chadwick]

@r3-za
Would you like to propose some text for inclusion in the data model document that describes how images can be embedded in VCs?

[r-soltani]

@David-Chadwick Sure I am working on some preliminary work. Where can we propose the schemes?

[David-Chadwick]

You can add it to this issue in the first instance to get some feedback. Then when it is a relatively stable you can do a pull request on the existing data model document in order to get the text included in the next update

[r-soltani]

This the data structure I have developed so far.

Type 1: Image embedded using the 'data' property

“data”: {
“label”:”passport1”,
“type”:”jpeg”,
“encode”, “base64”,
“content”: ”[content of image in base64]”
}

Type 2a: Image referenced on IPFS by specifying the protocol, host and hash

“data”: {
“label”:”passport1”,
“type”:”jpeg”,
“scheme” : “ipfs”,
“uri”: “104.131.131.82“
“digest”, “QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvu”,
}

Type 2b:I mage referenced on NI server by specifying the protocol, host and hash

“data”: {
“label”:”passport1”,
“type”:”jpeg”,
“scheme” : “ni”,
“uri”: “/ip4/104.131.131.82/tcp/4001/“
“digest”, “QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvu”,
}

I am not sure about the property names uri and digest..

[msporny]

I'm attempting to formulate this issue into some specification text or close the issue w/ no changes to the specification. I agree that being able to express an image is important and there have been a number of ways that have been explored in this issue. That said, the only spec text that could possibly change at this point is an example in the spec.

I suggest we do a PR that pulls in an image data URL. Describing images as @r3-za has outlined above is beyond the scope of the VC spec and is better explained via documentation on sites like schema.org or rNews and other IPTC specifications.

I suggest we submit a PR that shows a schema.org image property with a data-url as @davidlehn suggested above to resolve this issue.

[stonematt]

does solving this also solve issue #136