wenjing
commented
3 years ago Another way to look at it from this json structure of a presentation. The names are all the info to be returned. The verify.json file list is only the constrain part to match: 'presentation_request': { 'name': 'Proof of Software Certificate', 'version': '1.0', 'requested_attributes': { '0_software_certificate_uuid': { 'names': [ 'softwarename', 'softwareversion', 'developerdid', 'softwaredid', 'softwarehash', 'softwareurl', 'mediatype', 'sourcedid', 'sourceurl', 'sourcehash', 'buildertooldidlist', 'dependencydidlist', 'buildlog', 'builderdid' ], 'non_revoked': {'from': 0, 'to': 1622584411}, 'restrictions': [ { 'schema_id': 'UyDtaEFuTySAV9VZDykHkh:2:softwareCertificate:0.3', 'issuer_did': '3EgDXzVZ2grXvYXp5MEBnV', 'attr::softwarename::value': 'vsw', 'attr::softwareversion::value': '0.0.11', 'attr::softwareurl::value': 'https://files.pythonhosted.org/packages/af/a2/269b2 d19a6b9fd6dc2b504f91c7562fe9878b6edfecdc4a23407b0e9f872/vsw-0.0.11-py3-none-any.whl' } ] } }, 'requested_predicates': {}, 'nonce': '685348358638459761284423' },
The verfify.json file contains two parts of fields. (1) specified values that must match (i.e. search fields) (2) specified values that must return/retrieve - these values are to be returned to the verifier and displayed for the user to examine
Currently, it seems all fields are treated as (1).
Let me illustrate this issue with an example. User A wants to install software "vsw". Before installation, she wants to make sure that the download link can be trusted (the file had not been hacked), and the software is from the true developer X. X is a well known software developer whose public DID is known to everyone. She also decides to use version 0.0.10 that contains an important bug fix she needs. She can do so by this verify.json:
{ "requested_attributes": [ { "schema_id": "UyDtaEFuTySAV9VZDykHkh:2:softwareCertificate:0.3", "issuer_did": "3EgDXzVZ2grXvYXp5MEBnV", "attr::softwarename::value": "vsw", "attr::softwareversion::value": "0.0.10", "attr::softwareurl::value": "https://files.pythonhosted.org/packages/ee/d3/bf2b994670dc77d29c657ffdf1fc763207502c5b95a308dac7db50c3a050/vsw-0.0.10.tar.gz" } ] }
In this example, the repo uses softwareName, softwareVersion, softwareUrl to find a matching credential, and returns softwareHash value. The verifier compares the returned softwareHash with the Hash calculated from the downloaded tar.gz. If they match, return positive.
Note that even though the softwareHash field is not explicitly requested, it is implied. The attr::softwarehash::value is treated as requested.
Now, consider the second example. User B wants to have the same assurance as User A, but also wants to know from which source code repository the "vsw" software v0.0.10 is derived from. He would like to do a source code audit himself, for instance. So, he is asking repo to return a correct value for a field (not to compare with something he already knows, he doesn't know.) He also wants to review how the developer built it. This is essentially a query of the authentic database. He can do so by:
{ "requested_attributes": [ { "schema_id": "UyDtaEFuTySAV9VZDykHkh:2:softwareCertificate:0.3", "issuer_did": "3EgDXzVZ2grXvYXp5MEBnV", "attr::softwarename::value": "vsw", "attr::softwareversion::value": "0.0.10", "attr::softwareurl::value": "https://files.pythonhosted.org/packages/ee/d3/bf2b994670dc77d29c657ffdf1fc763207502c5b95a308dac7db50c3a050/vsw-0.0.10.tar.gz" "attr::sourceurl::value": "", "attr::sourcedid::value": "", "attr::sourcehash::value": "", "attr::buildertooldidlist::value": "", "attr::dependencydidlist::value": "", "attr::buildlog::value": "", "attr::builderdid::value": "" } ] }
Here the empty string value implies a query. The repo should return their values from a matching credential.
In summary, here are to issues to fix:
(i) Support "" string as a request to return its value. {ii) The verify command should always print out returned value (in json is ok).