You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Can SRI be used in JSON-LD and for which use cases? #86
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.
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
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
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
Activity
davidlehn commentedon Oct 25, 2018
See also: #9
iherman commentedon 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. metadataView 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 commentedon Jan 3, 2019
Also relates to discussions of #9 content addressable contexts as those would come with some amount of implicit integrity checkability.
iherman commentedon Jan 5, 2019
This issue was discussed in a meeting.
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
iherman commentedon 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 itView 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 commentedon Apr 27, 2019
Ref #108