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

Can SRI be used in JSON-LD and for which use cases? #86

Closed
ajs6f opened this issue Oct 25, 2018 · 6 comments
Closed

Can SRI be used in JSON-LD and for which use cases? #86

ajs6f opened this issue Oct 25, 2018 · 6 comments
Labels
security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response.

Comments

@ajs6f
Copy link
Member

ajs6f commented Oct 25, 2018

Subresource Integrity can be used in HTML to provide integrity support for portions of HTML documents. It may be possible to reuse that pattern in JSON-LD, and it might support various use cases around integrity, but the basic question of whether it can be done in JSON-LD syntax is still open.

@davidlehn
Copy link
Contributor

See also: #9

@iherman
Copy link
Member

iherman commented Dec 16, 2018

This issue was discussed in a meeting.

  • RESOLVED: azaroth to open an issue about annotating context URLs potentially with validity/integrity, etc. metadata
View the transcript Can SRI be used in JSON-LD for which use cases?
Benjamin Young: #86
Benjamin Young: https://w3c.github.io/webappsec-subresource-integrity/
Benjamin Young: if anyone understands this first issue, we can discuss it
Benjamin Young: … SRI = Sub-Resource Integrity
Benjamin Young: SRI is something HTML implementors use to state the integrity of things
… I believe adam wanted to introduce something like SRI for e.g., validating contexts
Gregg Kellogg: it’s an intriguing idea, esp. in the context of referencing external contexts
… it does come with a cost though..
… I think the motivation behind this was to provide means for side-loading stuff
Benjamin Young: https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata
Rob Sanderson: is it about whether we can use the abstract definition of integrity stuff SRI defines
Ivan Herman: there have been 2 diff. issues that came up during TPAC
… one of them was about using a local version of the context
… all go in the direction of annotating a link
… maybe we should postpone this specific issue until we investigated the general picture more thoroughly
Benjamin Young: yeah, people want to be able to state “more” things about a context than they currently can
Benjamin Young: related to #9
Benjamin Young: i.e., that it is sealed
… I don’t think we have any specific actions to take
Rob Sanderson: I think there’s some meta discussion going on
Proposed resolution: someone should open an issue about annotating context URLs potentially with validity/integrity, etc. metadata (Benjamin Young)
Rob Sanderson: we may need to introduce new keywords that identify “new metadata” about a context
… distinction between inline context and reference to metadata of external context
Proposed resolution: azaroth to open an issue about annotating context URLs potentially with validity/integrity, etc. metadata (Benjamin Young)
David I. Lehn: if such metadata feature exists, people may see that as a way to add comments and docs and such as in previous closed issues
Rob Sanderson: +1
Benjamin Young: +1
Rob Sanderson: we should not have the same discussion again in January
Gregg Kellogg: +1
Tim Cole: +1
Simon Steyskal: +1
Pierre-Antoine Champin: +1
David I. Lehn: +1
Ivan Herman: +1
Jeff Mixter: +1
Resolution #3: azaroth to open an issue about annotating context URLs potentially with validity/integrity, etc. metadata

@BigBlueHat
Copy link
Member

BigBlueHat commented Jan 3, 2019

Also relates to discussions of #9 content addressable contexts as those would come with some amount of implicit integrity checkability.

@iherman
Copy link
Member

iherman commented Jan 5, 2019

This issue was discussed in a meeting.

  • No actions or resolutions
View the transcript Ivan Herman: it is interesting, no doubt
… (puts admin hat on)
… these are very early drafts
… Manu made this proposal in December, very early days
… we’re fine, though.
… if the technique becomes a standard form for URIs, we can use it as such
… I’m happy to have us say that we are interested
… we should try to see whether this tech really can be used to annotate links while we also pursue other avenues
Gregg Kellogg: really like the idea, could be very useful
Gregg Kellogg: but not clear that it really affects our docs at all
… what would we change?
Ivan Herman: we shouldn’t close issues just because this new thing is a new thing
Gregg Kellogg: unless we think that we can do that via a reference in the best practice docs
Adam Soroka: if hashlink solves for problems we have, then we may not want to recreate alternative features that solve the same issues
Benjamin Young: although this new hash URI tech isn’t standardized, it has been put into use

@azaroth42 azaroth42 moved this from Discuss-Call to Discuss-F2F in JSON-LD Management DEPRECATED Jan 17, 2019
@azaroth42 azaroth42 moved this from Discuss-F2F to Discuss-GH in JSON-LD Management DEPRECATED Mar 7, 2019
@azaroth42 azaroth42 added defer-future-version Defer this issue until a future version of JSON-LD security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. labels Apr 19, 2019
@azaroth42 azaroth42 moved this from Discuss-GH to Future Work in JSON-LD Management DEPRECATED Apr 19, 2019
@iherman
Copy link
Member

iherman commented Apr 27, 2019

This issue was discussed in a meeting.

  • RESOLVED: Close syntax #86, as being dependent on deferred #108, and duplicates only use case for it
View the transcript Can SRI be used in JSON-LD and for which use cases?
Ivan Herman: #86
Rob Sanderson: answer is no
Ivan Herman: I propose this issue can simply be closed by referring to the previous issue
Proposed resolution: Close syntax #86, as being dependent on deferred #108, and duplicates only use case for it (Rob Sanderson)
Gregg Kellogg: +1
Benjamin Young: +1
Rob Sanderson: +1
Ruben Taelman: +1
Simon Steyskal: +1
Tim Cole: +1
Pierre-Antoine Champin: +1
Dave Longley: +1
David Newbury: +1
Ivan Herman: +1
David I. Lehn: +1
Resolution #5: Close syntax #86, as being dependent on deferred #108, and duplicates only use case for it

@iherman
Copy link
Member

iherman commented Apr 27, 2019

Ref #108

@iherman iherman closed this as completed Apr 27, 2019
@gkellogg gkellogg removed this from Future Work in JSON-LD Management DEPRECATED Apr 30, 2019
@azaroth42 azaroth42 removed the defer-future-version Defer this issue until a future version of JSON-LD label Nov 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response.
Projects
None yet
Development

No branches or pull requests

5 participants