Introduce concept of "sealed” contexts

[gkellogg]

A number of standards track specifications use JSON-LD for extensibility but intentionally place limitations on overriding the terms defined in a core context. For example:

Implementations may augment the provided @context with additional @context definitions but must not override or change the normative context.

https://www.w3.org/TR/activitystreams-core/#jsonld

Implementations MUST produce an error when an extension JSON-LD Context overrides the expanded URL for a term specified in the base JSON-LD Context (https://w3id.org/credentials/v1). To avoid the possibility of accidentally overriding terms, developers are urged to scope their extensions.

https://w3c.github.io/vc-data-model/#extensibility

It seems like it would be a nice feature to allow enforcement of this desire by JSON-LD processors. Then authors could be assured that the interpretation of a context would be proper and properly implemented JSON-LD processors would throw errors if rules were violated.

In short, I propose we add a keyword with boolean value such as "@sealed": true (that could appear in contexts) to JSON-LD 1.1 that enables processors to enforce a desire to prevent defined terms from being redefined in subsequent contexts, but allows for new terms (aka extensions) to be defined.

Original issue: Introduce concept of "sealed" contexts #656

[ajs6f]

@gkellogg This seems reasonable and useful to me.

Would sealing be a context-level-only feature? IOW, do you propose allowing some terms in a context to be sealed but not others?

[simonstey]

Would sealing be a context-level-only feature? IOW, do you propose allowing some terms in a context to be sealed but not others?

alternatively, one could also split the context into one sealed part and an unsealed one, and just import both right?

[ajs6f]

I imagine so, although the interweaving might be difficult... I'd have to work through some examples.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Defer #20 for TAG review for cross-specification issues of signing on the web ; confer with security regarding SRI and credentials regarding LDS vs byte hashing
• ACTION: Rob Sanderson to create context signature issue, related to #20

View the transcript

Rob Sanderson: back to issue 20
… sealed contexts
… introduced in the CG by dave longley in June
Gregg Kellogg: so the idea is that there is something in the context that says if a given context refers to something else that tries to override a known term
… that there is a way to prevent the overriding (but w/o stopping processing)
… one example, a context with a list of other contexts the others can’t overrride
… how do we cause overriding to take place when you absolutely need to? context:null?
… scoped contexts should do the same thing
Ivan Herman: who would freeze the context?
Gregg Kellogg: author
Adam Soroka: perhaps to avoid caching problems?
Gregg Kellogg: but that’s not what it means
… but they do work together
Ivan Herman: there is something in my forgotten past that is making me unhappy about this
Adam Soroka: the use case that gkellogg mentioned is a good one
Ivan Herman: once I have nulled things, I can do what I want anyway
… for an example, when there is something missing in schema.org we either come up with a our own term or we use a context to override
… but it’s not a very elegant solution, but it works and solves a need.
Gregg Kellogg: but you could just as well solve it by creating a new term but then schema.org isn’t going to recognize it
Benjamin Young: the sealed context goes against compaction
Gregg Kellogg: no it does not.
Benjamin Young: if you look on the playground this isn’t what I see…so maybe there is a difference between spec and implementation?
Gregg Kellogg: the sealed context is relevant in expansion
… by treating the input as always being expanded
… also algos start from expanded form
Rob Sanderson: I want to question the nuclear option
… if that is allowed, then why would that be useful instead of just specifying new context?
Gregg Kellogg: the reason to do it is that you don’t want to inherit things outside your scope
Rob Sanderson: if have a context that wipes out all the previous ones, then everything form that point is known
Gregg Kellogg: you can also set a single term to null
… as a way to undefine a single term
Adam Soroka: given ivan’s example, where I want to change the value type of a known term…that is quite different from completely overriding a term with completely different semantics.
… we should be sure that all use cases are addressed with the same solution
Gregg Kellogg: in the case of schema.org, we want to make it legitimate to avoid loading contexts
Dan Brickley: and be sure to differentiate search from other cases
Gregg Kellogg: verifiable claims wants sealed, but we’re not sure why
Benjamin Young: VC relies on LD signatures, and sealing ensures that the output graph (which is what is signed) is always the same.
Gregg Kellogg: but if they were defined in the scope of the client
Ivan Herman: which is why nuclear works
… they need a controlled environment and so they want to ensure that any previous state doesn’t impact the sig contexts
Benjamin Young: but their user data goes lower and the sig is the higher tree
… .they are the first context not the last
Dan Brickley: w.r.t. signature over this, there are some old experiments around signing schemas (links near https://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC/FOAF_Use_Case#Signed_RDF somewhere)
Adam Soroka: is this a real concern?
Adam Soroka: actually this is real, just ? whether sealed contexts can fix it
Gregg Kellogg: yes, if you could somehow (maliciously) change the context earlier on, then all breaks down
Dan Brickley: this could introduce some serious problems with nuclear overriding needed things
Dan Brickley: not feeling it. this doesn’t seem to align with the rest of the web and its use of JSON-LD
Ivan Herman: this seems to be useful from the security/sig concerns
Benjamin Young: but if you expanded everything then you wouldn’t have the problem
Ivan Herman: but can I add signatures to a context? verifying authenticity of a context
Action #3: Rob Sanderson to create context signature issue, related to #20
Gregg Kellogg: if we have a signature on a given context, has integrity, etc. - but that’s different from a new context
Adam Soroka: both could be valid or one/both could be malicious
Ivan Herman: the whole thing is a security thing that has to be built on top of JSON-LD
Benjamin Young: since the people that wanted it aren;’t here, so let’s not touch it right now. If we get it wrong, it will make things worse
… we need some use cases
Leonard Rosenthol: If we’re worried about signing things, we should do it consistently.
… there’s a mechanism in HTML to verify a linked resource - sub resource integrity - can we apply that there as well?
Benjamin Young: https://www.w3.org/TR/SRI/
Benjamin Young: https://w3c-dvcg.github.io/http-signatures/
Dan Brickley: (there’s some relationship between the subresource integrity and webpackging . that I don’t totally understand)
Leonard Rosenthol: also resource integrity might be useful here as well
Dan Brickley: signing of HTML+JSON, HTML+Microdata, HTML+RDFa, HTML+SVG, CSS, Javascript, Typescript, WebAssembly, GLSL, blahblah … should all have a common!
Benjamin Young: https://github.com/WICG/webpackage
Dan Brickley: what happens when we come to a future TPAC and everyone has their own signatures :(
… integrity and signatures isn’t the scope of this group
Gregg Kellogg: this seems like something for HTML or Web Platform
Benjamin Young: put some links in the chat for various other options
… LD signatures might be part of DID but they are debating it there
… so let’s kick the can over to them and see what happens.
Ivan Herman: that being said, SRI is so simple that we might consider how we could use it for contexts.
… it certainly doesn’t solve anything, but it would be useful
Benjamin Young: the may be some issues about exactly what are you validating/checking.
… there are some known issues, but we may be able to work around those with some specific info about JSON-LD
Leonard Rosenthol: SRI is just hashing a “binary stream”
Leonard Rosenthol: we need an action item to create an issue around use of SRI
Gregg Kellogg: thinks we discussed this last TPAC
Ivan Herman: how would the syntax work?
Gregg Kellogg: yes, we’d have to work on that
Proposed resolution: Defer #20 for TAG review for cross-specification issues of signing on the web ; confer with security regarding SRI and credentials regarding LDS vs byte hashing (Rob Sanderson)
Leonard Rosenthol: +1 to proposal
Ivan Herman: +1
Rob Sanderson: +1
Benjamin Young: +1
Adam Soroka: +1
Gregg Kellogg: +1
Benjamin Young: https://www.w3.org/TR/2014/WD-SRI-20140318/
Benjamin Young: wanted to point out that RFC as well which is much better than the current SHA expression as used in SRI
… not our problem and lots of solutions
Harold Solbrig: +1
Simon Steyskal: +1
Resolution #2: Defer #20 for TAG review for cross-specification issues of signing on the web ; confer with security regarding SRI and credentials regarding LDS vs byte hashing

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

Dave Longley: we wanted to talk about onboarding allies from the JSON world
… a number of W3C specs have adopted JSON-LD, to get extensibility and interoperability
… however, a number of non-RDF people are only going to use this data as plain JSON
… not apply any JSON-LD algorithm
… Most of those standards require that their context is the first one in the @context list;
… and have the rule that terms from their context should not be overridden.
… Result: plain JSON interpretation will differ from JSON-LD interpretation.
Rob Sanderson: if the JSON-only processor does not use the context at all, where’s the risk?
Dave Longley: E.g. Verifiable Credentials defines a ‘description’ field;
… if someone uses an additional context redefining ‘definition’ to mean something else,
… a pure-JSON tool will still interpret that as the VC description field.
… The ‘sealed context’ feature is required to make JSON-LD-based formats robust,
… reducing the gap btw JSON and JSON-LD.
… JSON people understand how JSON-LD can help interoperability,
… rather than having anyone defining their own schema,
… but they don’t have an RDF background.
Ivan Herman: the idea of a ‘sealed context’ is to prevent people from overriding terms in the first context.
… Wouldn’t it break the expectation of someone publishing their own data with their own vocabulary?
Dave Longley: this only applies in the case you are using a array of contexts
Christopher Allen: In constructing VC examples or DID examples,
… I ran in problem linked to the underlying graph model, that only Dave or Manu could explain.
… In VC, I want to be able to put some metadata of my own,
… something that’s not standardized or even ready for standardization,
… how do we put it in a way that we are not messing up other things?
Dave Longley: many people don’t get that curly braces in JSON-LD mean that you are talking about a node,
… and attributes are about the links in this graph;
… those people tend to produce data that make no sense for people who understand those principles.
Benjamin Young: I came to JSON-LD from an RDF-aware background
… I want to make things clearer,
… but not at the price of hiding completely the graph model from Web developers.
Adam Soroka: +1 to bigbluehat
Benjamin Young: Anecdote: in some plain-JSON formats, the same attribute ‘name’ does not expect the same type at different levels of the tree. You don’t have that in JSON-LD.
Christopher Allen: We are at a jey point where a lot of people are using JSON-LD.
… We don’t want them to decide that they will just do JSON and forget about the LD.
Gregg Kellogg: would the solution be a set of best practices?
Ivan Herman: Question: who is expected to seal a context? The author of the context or the author of the data?
Dave Longley: This is an open question.
… The notion of sealed context is one way to hide the graph model .
… Best practices, and anything that makes people aware that there is something beyond JSON, is a non-starter.
Benjamin Young: for you, sealed context only apply for arrays of contexts?
Dave Longley: yes, in all the use cases that I know of.
… If someone publishes a new context which extends another one,
Dave Longley: they can decide to override terms of the inherited context.
… As this would be a totally differen thing from the POW of pure-JSON.
Ivan Herman: Would it make sense to introduce a JSON datatype?
… I could put a bunch of JSON in the JSON-LD, that would be interpreted as an RDF literal with the JSON datatype.
Benjamin Young: but then you would have problems for signing, because you couldn’t determine the exact value of that literal (re. new lines, spaces…).
Dave Longley: yes, that raises a number of other issues.
Benjamin Young: One use case in VC is to be able to express an inner graph, with its own context,
… without compromising the outer graph with the VC metadata.
… In the old days, we would have used namespaces.
… Why not use “vc:” in front of the terms you want to keep uncompromised?
Dave Longley: The prefix wouldn’t survive some JSON-LD applications,
… and would produce something different from the POV of plain-JSON.
Rob Sanderson: Is it the expension that’s the issue? Or the compaction as well?
… Is it only about the label or the rest of the definition (e.g. “@type”: “@list”)?
Dave Longley: the full term definition has to be a constant.
Ivan Herman: in the first round, let’s stick to sealing contexts, not individual term definitions
… What we are trying to do is to add a “modifier” on the “@context” link.
Adam Soroka: The notion of wrapping is important in this use case.
… Is “sealing” not a special case of prioritization,
… which might have more complex requirements?
Dave Longley: ActivityPub also have requirements for priority.
… Their answer is “if you nee priorities, use full-fledged JSON-LD”
Dave Longley: re. WC, we could ask people to include their own @context,
… but that could not work in all cases.
Benjamin Young: pchampin suggested earlier to required that the sealed context be in the end,
… so it will effectively not be overridden with the current rules.
Gregg Kellogg: yes, but putting the extension before the extended context would be odd
Rob Sanderson: if terms are marked sealed, and the extension redefines that term,
… the overridden term will not be sealed, which can be detected by a validator
… This could mitigate the problem.
Ivan Herman: what if we have two sealed contexts in the list?
Dave Longley: then we would also need order priority…
Pierre-Antoine Champin: seems to me we’re discussing two different things with multiple contexts
… extensions
… which are aware of the sealed context
… and it would therefore be carefully designed to not conflict
… the other scenario is a “wrapping” one
… where the contained statements are expected to not match the wrapper
Benjamin Young: regarding the wrapping scenario, JSON-LD has graph containers.
Dave Longley: VC is using that.
Benjamin Young: could we solve the problem by adding some mechanism at the graph containers level.
Dave Longley: that would only work in named graph. That might solve my problem, but may be not others’ (activity streams).
Benjamin Young: following pchampin’s idea that there are two different categories, may be two different solutions are the way to go.
Benjamin Young: #87
Ivan Herman: to wrap up, the options that we considered are
… 1/ modify the semantics of graph containers
… 2/ having a “sealed”: true attribute in the context
… 3/ having a “sealed”: true within term definitions
… 4/ having the equivalent of a “rel=” attribute on the “@context” link
Gregg Kellogg: when you seal, are you sealing the local context or the active context?
Gregg Kellogg: seal and integrity should be treated separately
Benjamin Young: why not just go for putting the sealed context in the end?
Gregg Kellogg: because the following contexts will usually rely on the definitions in the first (sealed) context.
… e.g. after importing the schema.org context, I know I can use the xsd prefix.
Rob Sanderson: ref: https://iiif.io/api/presentation/3.0/#45-linked-data-context-and-extensions

[dlongley]

Hello!

An idea was proposed at the meeting at TPAC that this issue could be addressed by simply ordering "extension" contexts first and "core" contexts last in an @context array. We've considered it and it doesn't work for a number of reasons.

First, there's the aesthetics of it (people would prefer a "core" @context to come first in the array) but there are also more serious technical problems. Here's one example:

http://tinyurl.com/ycrgkeyy

Here a SpecificCredential with a scoped context for the issuer property overrides the base definition for issuer with the extension -- causing evil/confusion. The issuer property MUST NOT be overridden, yet it is.

I think it would probably be best to create a "sealed"/"frozen" @context feature and, while we're at it, make it use the more "expected" order of precedence (for this feature). I think this feature is really essential for JSON-LD adoption as "the way" to do extensions in specs for open world data models.

[BigBlueHat]

@dlongley thanks for that example! Scoped contexts do introduce a whole new layer of complication/confusion/unexpectedness... That said, I'm not sure the current array ordering is that unintuitive/unexpected.

Developers (especially general Web developers) are very familiar with "cascading" thanks to CSS. Things currently work this way with JSON-LD @context values.

It's also the way JavaScript (ECMAScript)'s Object.assign() works--last one wins:

a = {'test': 'ing'};
b = {'test': 'er'};
console.log(Object.assign({}, a, b));
// Object { test: "er" }

And, it's also the way ES6's Object Rest/Spread Properties work:

a = {'test': 'ing'};
b = {'test': 'er'};
console.log({...a, ...b});

Consequently, I'd find flipping the order more confusing and intuitive--and out of keeping with the surrounding code one would write to create the local context. So, I'd be 👎 on flipping that order--especially between JSON-LD minor point releases. Sorry.

I'll leave the continued discussion around sealed contexts--especially as it relates to the scoped context example you gave for another time. 😃