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

8.2 Content Integrity Protection #494

Closed
nadalin opened this issue Mar 27, 2019 · 12 comments
Closed

8.2 Content Integrity Protection #494

nadalin opened this issue Mar 27, 2019 · 12 comments
Labels
pending close Close if no objection within 7 days
Milestone

Comments

@nadalin
Copy link

nadalin commented Mar 27, 2019

This is another reason to no make the @context mandatory, this is not needed when using JWT/CWT.

@burnburn burnburn added this to the CR-Exit milestone Mar 27, 2019
@brentzundel
Copy link
Member

It is unclear to me how using a JWT to sign a property whose value is a URL, guarantees the integrity of the content located at that URL. Could you help me understand this?

@nadalin
Copy link
Author

nadalin commented Mar 28, 2019

If this is a JWT and what is pointed to via URL is a JWT you have integrity protection

@brentzundel
Copy link
Member

Ah, thank you. So as long as the URLs are "JWTS all the way down" there isn't a problem with content integrity. I think the content integrity protection section should probably be updated to point out that fact.

@dmitrizagidulin
Copy link
Contributor

@nadalin

If this is a JWT and what is pointed to via URL is a JWT you have integrity protection

This is not quite the case, though, which is what I think what @brentzundel's concern was. JWTs provide integrity protection of their payload, but not of the binding between a URL and the contents of a particular document.

The latter type of binding requires a separate mechanism such as Hashlinks.

@brentzundel
Copy link
Member

@nadalin, do you have a specific recommendation regarding a change you would like to see made to section 8.2?

If not, perhaps this would be better as a comment on issue #483, rather than as an issue in its own right.

@nadalin
Copy link
Author

nadalin commented Apr 2, 2019

@dmitrizagidulin I don't see the requirement for this linkage for integrity protection in the specification at all

@stonematt
Copy link
Contributor

WG resolution: https://www.w3.org/2019/04/02-vcwg-minutes.html#resolution05
RESOLUTION: The content-integrity section of the specification describes how outgoing links from a document may be protected. Issue #494 asserts that JWTs provide content-integrity protection for outgoing links, which is false.The VCWG is also supportive of the use of @context as a core part of the data model. Issue #494 should be closed with no changes to the specification.

Will close 7 days from today if no additional concerns or evidence are raised by then in this issue.

@stonematt stonematt added the pending close Close if no objection within 7 days label Apr 5, 2019
@nadalin
Copy link
Author

nadalin commented Apr 8, 2019

@stonematt So when using just JWT as claims your statement is false as it provides content integrity, so my concerns remain

@brentzundel
Copy link
Member

@nadalin could you help me understand the mechanism by which JWTs provide content integrity protection for the content of outgoing links?

@nadalin
Copy link
Author

nadalin commented Apr 25, 2019

@brentzundel Not all claims will have out going links, the links are protected by JWS but not the contents of the links

@brentzundel
Copy link
Member

Okay, I think we've been talking past each other.

There is no question in the WG that JWTs provide integrity protection for the contents of the VCs that are serialized as JWTs.

This section specifically addresses the fact that content integrity protection may be necessary for the contents of links and makes some non-normative statements about that.

@burnburn
Copy link
Contributor

I believe this issue has been resolved with the additional explanation provided by @brentzundel , and no further comments have come in over the past 19 days. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pending close Close if no objection within 7 days
Projects
None yet
Development

No branches or pull requests

5 participants