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.

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

Add a section on referencing or embedding external credentials. #51

Merged
merged 4 commits into from Aug 27, 2019

Conversation

dmitrizagidulin
Copy link
Contributor

@dmitrizagidulin dmitrizagidulin commented Aug 27, 2019

Addresses issue #4.


Preview | Diff

index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated
credentials are issued by the same entity, the verifier has a high level
of trust and confidence in the issuer's security and auditing mechanisms, and
the value of the credentials is sufficiently low. However, this is not
recommended, and goes against the philosophy of <a>verifiable credentials</a>.
Copy link
Contributor

Choose a reason for hiding this comment

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

I disagree. It does not go against the philosophy of VCs. Please delete the whole section starting with However, this is not.....
The referenced credential may be just as valid as the referencing credential since tampering with either will normally be just as difficult for an attacker.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

A large part of the purpose of Verifiable Credentials (the verifiable part) is that they contain tamper-evident mechanisms like digital signatures.
The thing about linking to external credentials is that the digital signature on the content of one of them (without an equivalent mechanism in the link itself) will give users a fall sense of security, since they may assume (incorrectly) that the signature also somehow binds or protects the content of the other credential.

To put it another way, if you're not cryptographically binding the contents of the other credential, why use a verifiable credential in the first place? Why not use a regular one?

The example given of just simply using a foreign key (like referencing a PO Number for an Invoice credential), that's very commonly done, I agree. But it's done in use cases where there's a very low threat of tampering, in which case, why use a verifiable credential at all?

<a>verifiable credential</a> is to use a linking mechanism that
cryptographically binds the contents of the target document to the URI itself.
One way to accomplish this would be to use <a>hashlinks</a> or an equivalent
URI scheme. Another mechanism would be to encode the full contents of the
Copy link
Contributor

Choose a reason for hiding this comment

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

I dont see the point in encoding the full contents, especially if the issuer is the same for both credentials. I suggest deleting the section starting Another mechanism

index.html Outdated Show resolved Hide resolved
@deiu deiu merged commit 06de3ce into w3c:gh-pages Aug 27, 2019
@dmitrizagidulin dmitrizagidulin deleted the hashlink branch August 27, 2019 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants