Skip to content

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

Closed

Description

@ajs6f

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.

Activity

  1. davidlehn commented on Oct 25, 2018

    @davidlehn
    Contributor

    See also: #9

  2. iherman commented on Dec 16, 2018

    @iherman
    Member

    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
  3. BigBlueHat commented on Jan 3, 2019

    @BigBlueHat
    Member

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

  4. iherman commented on Jan 5, 2019

    @iherman
    Member

    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
  5. added
    defer-future-versionDefer this issue until a future version of JSON-LD
    security-trackerGroup bringing to attention of security, or tracked by the security Group but not needing response.
    on Apr 19, 2019
  6. iherman commented on Apr 27, 2019

    @iherman
    Member

    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
  7. iherman commented on Apr 27, 2019

    @iherman
    Member

    Ref #108

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    security-trackerGroup bringing to attention of security, or tracked by the security Group but not needing response.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions