Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Hashed claim values #47

Merged
merged 6 commits into from Aug 28, 2019
Merged

Hashed claim values #47

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
243023d
Update index.html
David-Chadwick Aug 22, 2019
249b281
Update index.html
David-Chadwick Aug 22, 2019
c491b00
Update index.html
David-Chadwick Aug 27, 2019
ab67ef2
Update index.html
David-Chadwick Aug 27, 2019
1385a14
Update index.html
David-Chadwick Aug 28, 2019
288a262
Update index.html
David-Chadwick Aug 28, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
13 changes: 12 additions & 1 deletion index.html
View file
Open in desktop
Expand Up @@ -1621,7 +1621,7 @@ <h3>Selective Disclosure</h3>
Selective disclosure is the ability of a <a>holder</a> to select some elements
of a <a>verifiable credential</a> to share with a <a>verifier</a>, without
revealing the rest. There are several different methods which support selective
disclosure, we provide two examples:
disclosure, we provide three examples:
</p>
<ul>
<li>
Expand All @@ -1642,6 +1642,17 @@ <h3>Selective Disclosure</h3>
all of the credential's claims to be revealed.

</li>
<li>
<b>Hashed Values</b> - With this method, the <a>issuer</a> issues a single
<a>verifiable credential</a> containing all the <a>issuer</a>'s <a>claims</a>
about the subject.
However, each <a>claim</a> value is created by hashing the actual value with
a different nonce so that the <a>verifier</a> cannot determine the actual value.
There are several different ways of modeling this, and
no standard way is currently defined. The <a>holder</a> includes the actual
values of the <a>claims</a> that are to be revealed to the <a>verifier</a> in
the <a>verifiable presentation</a>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More rewording is needed. Perhaps replacing your "actual value" with "original
literal value" would work... as --

However, each <a>claim</a> value in the <a>verifiable credential</a> is created
by hashing the original literal value with a different nonce. The value for the
<a>claim</a> in the <a>verifiable credential</a> then comprises an object
containing 1) the nonce and 2) the hashed value of the nonce concatenated with
the original literal <a>claim</a> value. In addition, the
<code>credentialSubject</code> contains the identifier of the hashing algorithm
used to create all the hashed values. The holder includes the original literal
values of the <a>claims</a> they intend to reveal to the <a>verifier</a> in their
<a>verifiable presentation</a>.

I am a bit confused by the <code>credentialSubject</code> contains the identifier of the hashing algorithm. Does the <code>credentialSubject</code> here not contain the identifier of the subject of the credential? Or does it include both identifiers (making it an array, rather than a single value)? Or something else?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that 'actual value' is better than 'original literal value'

The credentialSubject comprises a whole set of attributes, including the id. This is a proposal to add another property to this set i.e. the hashing algorithm. I will clarify this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a hashing algorithm as a property of a credentialSubject makes very little sense. It would mean, for example, that a VC about David Chadwick would state that David has a hashing algorithm of SHA-256.

It sounds like this information should be captured in the proof section somewhere instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The hashing algorithm is actually a property of the claim value e.g. the claim {name=David} is transposed into {name={hashID=SHA-256, nonce=123....9, value=a8clyga}}. But since the same hashing algorithm is used for all claim values, there is no point in repeating the hashing algorithm ID multiple times. So we move it up a level to the encapsulating object, which is the credentialSubject, and put it there.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has this been resolved? I lean towards what @dlongley said above. The hashing algorithm, and all cryptographic attributes should be decoupled from the contents of the credentialSubject.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we had a data model in which a credentialSubject contained an ID and a set of claims, and each claim contained an ID and a set of properties, then we could have explicitly placed the hashID in the claim object. But unfortunately the data model has not explicitly identified the claim object with a claim ID and so the fact that this exists is obscured (and has led to many previous misunderstandings and issues.) Thus you think (wrongly) that the hashID is a property of the credentialSubject, when in fact, it is a property of the (invisible) claim object.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@David-Chadwick, btw, (we don't need to mention this), but there has been other exploratory work in this area that involves reducing nonce storage via HMAC keys and that transforms the data to RDF quads prior to hashing -- and other work that uses URLs to store the hash values.

I think given that there are a number of ways to do the above scheme that we should perhaps just leave a note saying that it is up to the proof scheme to figure out how it's done -- like we do with ZKPs. We won't need to debate this further if we take that approach. It's worth just noting the nonce+hash method here as a means of redaction. We can also point to the CCG for further work in the area.


</ul>
<p>

Expand Down