Remove @vocab from the base context.

[msporny]

This PR is a partial attempt to address issue #1514 by removing @vocab from the base context because we no longer have WG support for this specific usage of the feature.

Other forthcoming PRs will provide new guidance on when and how to use @vocab safely.

---

Preview | Diff

[tplooker]

Im just going to highlight for one more time, in case this point has been missed by others.

This PR and related issue #1514 has been re-raised because of this security disclosure made around DI. Removing @vocab from the base context which is what this PR is doing, does nothing to fix the underlying issues outlined in the security disclosure. Put another way @vocab is still a thing in JSON-LD whether it exists in this context or not, hence we should be focusing on fixing it, not avoiding its usage in certain contexts.

I still think its better from a developer experience to have @vocab in the core context, provided the feature can be made safe. However, this isn't a hill I'm willing to die on any more so I won't be approving this PR, nor will I block it.

[iherman]

Looking at the minutes of our meeting, many on the call were in favor of adding something about an inline @vocab. Actually, for several persons on the call, this was the "good compromise".

I think we should add (possibly in a separate, editorial note) something along the lines of:

If developers nevertheless want to use the @vocab feature for development and experimentation purposes, it is advisable to use it as part of an embedded context, i.e.,

{
    "@context" : [
       "https://www.w3.org/ns/credentials/v2",
       { "@vocab": "https://www.example.org/myExperiments/" }
   ],
  … 

This embedded context can be easily replaced by a reference to a final, application-dependent context file, once available.

[iherman]

Hi @tplooker,

Put another way @vocab is still a thing in JSON-LD whether it exists in this context or not, hence we should be focusing on fixing it, not avoiding its usage in certain contexts.

My apologies if I misunderstand it, I am a late arrival to that whole discussion, but my understanding is that "fixing it" would involve changes in the JSON-LD specification. The JSON-LD Working Group is currently in maintenance mode, and I am not sure whether it is chartered to make significant changes to the specification. But even if it is, such a change takes a very long time. This means this is not an option for us imho.

At this point, what we can do is to draw the attention of developers to the issue, and this is what this PR tries to do (also based on the WG discussion).

I still think its better from a developer experience to have @vocab in the core context, provided the feature can be made safe.

See above. That being said, the group recognized that developers may have valid reasons to use this; see my comment above: #1520 (comment).

[aniltj]

I support the removal of @vocab from the base context.

I also support @iherman's language in #1520 (comment) of using @vocab for developmental purposes as an additional in-line context, so anticipate that will be a separate PR that will be raised.

[tplooker]

My apologies if I misunderstand it, I am a late arrival to that whole discussion, but my understanding is that "fixing it" would involve changes in the JSON-LD specification. The JSON-LD Working Group is currently in maintenance mode, and I am not sure whether it is chartered to make significant changes to the specification. But even if it is, such a change takes a very long time. This means this is not an option for us imho.

I understand the complexity here @iherman but the in-escapable reality is we have a feature in JSON-LD that creates security issues in DI, so I think we need to focus on fixing that, what ever that may involve rather then simply trying to limit the usage of the problematic feature in certain contexts.

At this point, what we can do is to draw the attention of developers to the issue, and this is what this PR tries to do (also based on the WG discussion).

I'm quite uncomfortable if this is the best we think we can do here, there are solution options highlighted in the DI issue that are being considered which would fix this.

Looking at the minutes of our meeting, many on the call were in favor of adding something about an inline @vocab. Actually, for several persons on the call, this was the "good compromise".

Side note, I assumed from comments in other threads that inline contexts were "bad practise" see here for an example. If these aren't and in fact are allowed then that makes security issue highlighted here much harder to mitigate without say integrity protecting the @context entries.

[selfissued]

I do not support removal of @vocab from the base context. The reasons it was put there remain valid.

Among other such reasons, it was documented that some JSON LD implementations omit undefined terms and types from the derived RDF. That means, that, for instance, if a JSON object includes a type error, the entire thing will be removed before signing. That means that attackers can change anything in the removed JSON object without affecting the signature.

Using a default @vocab prevents these attacks from being possible.

[dlongley]

@tplooker,

I understand the complexity here @iherman but the in-escapable reality is we have a feature in JSON-LD that creates security issues in DI...

So, I don't want to bring that other issue over here, but I wanted to quickly say that this feature does not create security issues in DI. Consuming terms from contexts that are not understood is not spec conformant and doing so is what creates the security issue. Anyone following the specs does not have this security problem because they know they cannot consume a term by just assuming what it means -- rather than understanding the context that defines it.

---

Currently @vocab is in the core VC v2 context, acting as a "catch all" fallback, where it only provides a term definition for a JSON key if no other contexts define a term mapping for that JSON key. This necessarily means that all contexts have to be understood in a document in order to consume any term in that document. Otherwise, how could you know where the definition for a term came from? Was it from one of the unknown contexts or did it fallback to @vocab?

It will never be the case that using @vocab in this way would allow anyone to ignore any contexts in a document, even if they aren't consuming any terms defined by those contexts.

This has not been an obvious logical conclusion, tripping some developers up. Now, just because some developers get confused about a feature does not mean we should ban that feature. However, I'm for removing it from the core VC v2 context because I think it's better for terms to be globally unambiguous in production systems as I've stated elsewhere.

Note: Altering JSON-LD itself doesn't allow us to avoid the logical conclusion above. If we were to add a JSON-LD @vocab "protection" feature, it would mean that having @vocab in the core VC v2 context would prevent all other term definitions in all other contexts. I explained this in the other issue.

To try and be extra clear again here, it is a logical impossibility to do these two things at once:

1. Have @vocab be in the core VC v2 context as a "catch-all" fallback for defining otherwise undefined terms.
2. Safely ignore unknown contexts that define terms in a document.

You simply cannot know whether a term was defined via @vocab or via those unknown contexts. Changing JSON-LD itself would just result in an error being thrown whenever any additional context appears after the core VC v2 context. Clearly there is not consensus to do this as it would prohibit every use case that doesn't solely rely on @vocab.

+1 to removing @vocab from the base context.

[dlongley]

@selfissued,

Among other such reasons, it was documented that some JSON LD implementations omit undefined terms and types from the derived RDF. That means, that, for instance, if a JSON object includes a type error, the entire thing will be removed before signing. That means that attackers can change anything in the removed JSON object without affecting the signature.

It is non-conformant to silently drop terms. The test suite will have (or may already have) tests to confirm an implementation does not do this.

[PatStLouis]

I'm in favor of removing @vocab from the base context.

@iherman another option is to use the https://www.w3.org/ns/credentials/examples/v2 context.
I personally like using the issuer-dependent page as it will give some information.
Maybe the recommendation could be to use {"@vocab":"https://www.w3.org/ns/credentials/issuer-dependent#"} inline.

There could even be a context url provided for this purpose, https://www.w3.org/ns/credentials/issuer-dependent/v2, which would essentially move the current @vocab to its own context file.

[aljones15]

Approving and +1 to @PatStLouis 's idea of using the examples context.

[PatStLouis]

@selfissued wouldn't this require a non-conformant issuer and a non-conformant verifier?

Reading the specification:

Implementations that use JSON-LD processing, such as RDF Dataset Canonicalization [RDF-CANON], MUST throw an error, which SHOULD be DATA_LOSS_DETECTION_ERROR, when data is dropped by a JSON-LD processor, such as when an undefined term is detected in an input document.

This addresses your concern directly.

The main reason this was added was to make it easier for implementers to do development and add JWT private claims interoperability.

The current vocab file used reads that this is for:

closed applications, experiments, or examples

Having development features in a production system is not a valid reason in my opinion while you seem to argue that it is.

[msporny]

I do not support removal of @vocab from the base context. The reasons it was put there remain valid.

As the group highlighted during the call this past week, we do not have consensus to include the @vocab feature in the base context. This PR removes it from the base context.

Even if there are many more people that step forward and object to the PR, that will not change the fact that there are multiple people that are not supportive of this feature. IOW, we do not have consensus for the feature, so we must remove the feature.

Saying that one doesn't support the removal of the feature does nothing for a feature that does not have consensus (other than signal that you're displeased about the fact that we do not have consensus for a feature).

Among other such reasons, it was documented that some JSON LD implementations omit undefined terms and types from the derived RDF. That means, that, for instance, if a JSON object includes a type error, the entire thing will be removed before signing. That means that attackers can change anything in the removed JSON object without affecting the signature.

Others in this thread have pointed out why your statement is incorrect.

Using a default @vocab prevents these attacks from being possible.

A default @vocab (in production) covers up that there is a problem and makes it not easily possible to catch that there is a problem, which was initially argued many months ago when the feature was first added into the base context. It was a bad idea back then, and it is a bad idea now. It's good that the WG has come to this realization before it was too late.

[decentralgabe]

I'm on the fence with this change. I understand the reason and risk of including @vocab, but it is a reason I'm still promoting the use of W3C VCs within the ecosystem I work in--to maintain compatibility with the data model while not wanting to do LD processing or create and manage our own contexts.

The comments you made on the last call, @msporny, suggest that you believe that this door has been "closed" and folks who don't want to do LD processing have already moved to the IETF or other groups. I don't see it the same way -- the door is still ajar, before this PR.

Given how many credentials I have encountered (and I'm sure others too) that claim to conform to the 1.1 data model but completely ignore LD processing to the degree that LD processors would break...I am still sympathetic to reducing the burden on these implementers. Making more credentials conformant, and breaking fewer processors is a north star for me. If we achieve that, we'll achieve a successful data model.

Now, I completely see the other side: the data model is an LD data model. If folks don't do LD processing (to some degree..) they're signing themselves up for a bad time. Instead of increasing interoperability we're increasing the illusion of interoperability and potentially, confusion. Bite the LD bullet or go to the IETF. It's a simpler and clearer line in the sand.

I have not come to a conclusion yet, just sharing my thoughts. My instinct is that perhaps we could publish and maintain a context with just @vocab like

{
  "@context": {
    "@protected": true,
    "@vocab": "https://www.w3.org/ns/credentials/issuer-dependent#"
  }
}

That we provide as an option -- with necessary caveats and warnings -- for implementers that want to keep the door ajar. I would not go as far as to say it SHOULD NOT or MUST NOT be used in production use cases.

[selfissued]

we do not have consensus to include the @vocab feature in the base context.

We do not have consensus to remove @vocab from the base context. Lacking such consensus, the status quo should be maintained.

[tplooker]

@PatStLouis wrote:

If it's not a remediation I would suggest removing it as a remediation proposal from your shared slides (page 16) as this creates confusion.

Proposal 2 page 16 directly mentions @vocab in the vcdm 2.0 context as an issue and the proposal is exactly what is being proposed here. To quote:

Please re-read that slide in its full context. If you look below the text you have quoted, I highlight the issues with it as a proposed solution. In general this section of the slide deck is a brief discussion of different possible solutions including whether they actually solve the problem, the tradeoffs AND what else would need to be true for them to potentially be a solution. I express clear doubt about this particular "solution" in the first sentence and go on to cite my reasons why.

@PatStLouis wrote:

It does mitigate the risk for malicious actors to redefine terms from the core vcdm context.

We finally agree on something :) which is that @vocab allows one to maliciously redefine terms. Now whether that context be the core vcdm or otherwise we must fix the issue rather then just trying to avoid its usage in certain contexts, because that would be as I've said before just avoiding the problem. And if we do that then IMO we don't need to remove @vocab from the core context because its usage becomes safe.

[msporny]

@decentralgabe wrote:

@msporny thanks, sounds like we are on the same page with how to proceed. Should we include the @vocab context here for simplicity?

Raised in PR #1525 (to try to keep the decisions on each PR simple and not mix in other concerns/arguments).

[msporny]

@PatStLouis wrote:

@decentralgabe respectfully, you seem to be promoting the feature for a use case it was not intended for. This is another reason why I would advocate to remove it. Exploits usually derive from features being used for a different purpose than they are intended from.

I believe @PatStLouis is saying "@vocab wasn't intended to be used to declare a global issuer-dependent term vocabulary URL that would be shared among developers in different market verticals"... and if so, he's right, it wasn't developed for that. The VCWG is using it to do that, but, speaking as one of the people that designed and put that feature in the JSON-LD specification over a decade ago, @PatStLouis is correct... it was never meant to be used in the way VCWG ended up using it, just as a while(true) loop is rarely the right construct to use in a program. It's legal, but that doesn't mean it's a good idea or was among the intended use cases for the feature.

@decentralgabe wrote:

@PatStLouis please do your homework before making such accusations.

Seems like he did do his homework in this case. Also, with the standard CEPC reminder to everyone in the thread, this is "Unacceptable behavior" / "Patronizing language or behavior" / "Intentionally or unintentionally making assumptions about the skills or knowledge of others"

https://www.w3.org/policies/code-of-conduct/#unacceptablebehavior

... and I say that knowing that you're one of the more pleasant, even keeled, and thoughtful members of the group, and I can assure you that @PatStLouis matches you on each measure.

The written word really is a terrible medium for conveying nuance. :)

[decentralgabe]

@PatStLouis @msporny

I apologize for my language and have edited my original comment. This is a valuable discussion, and I'd like to contribute to keeping it constructive.

Pat, your opinion and contributions are welcome, regardless of your involvement in previous discussions. I'd like to clarify the point I was trying to make regarding:

@vocab wasn't intended to be used to declare a global issuer-dependent term vocabulary URL that would be shared among developers in different market verticals ...

This statement is uncontroversial. However, the key point is:

The VCWG is using it to do that ...

In the original issue (#953), a primary motivation was lowering the barrier to entry for developers new to JSON-LD, enabling them to create valid Verifiable Credentials more easily. My advocacy for keeping @vocab aligns with this goal of maintaining accessibility for a broader range of implementers.

You correctly note that the original discussion mentioned use cases like development, experimentation, and closed applications. However, I believe the line between these use cases can be blurry, and so can the intention of the text itself.

My prior comment—and this comment—are responding to your statements:

Having development features in a production system is not a valid reason in my opinion while you seem to argue that it is.

@vocab was added for development purposes

... you seem to be promoting the feature for a use case it was not intended for.

This is exactly a use case it was intended for, as evidenced by @OR13's original comment in #953:

By adding @vocab to the core data model context, we can give these developers the same experience they have with JWT private claims, which you should read about here: rfc7519#section-4.3

There's an important distinction to make here. The goal of 'helping developers' isn't limited to assisting with development-stage work; it extends to supporting developers in creating production-ready systems. When we talk about features that aid developers, we're often referring to tools and approaches that simplify the process of building robust, deployable solutions. In this context, using @vocab isn't just a 'development feature,' but rather a tool that can streamline the creation of production-grade Verifiable Credentials. This aligns with the original intent of lowering barriers for developers working on real-world implementations, including those destined for production environments.

To be fair, @msporny noted in multiple comments in #953 the risks of using @vocab in production systems. However, @OR13 disagreed with this assessment. Regardless, the change merged in #1001 did not provide normative guidance (or any guidance) on not using @vocab in production systems. #1420 did add normative language here, though, reflecting now I am not clear that I nor some other members in the group fully understood the impact of this language (even though the language is SHOULD NOT not MUST NOT).

Given this context, I believe your assertions do not accurately reflect the original intent of including @vocab in the base context. I am indeed promoting the use of @vocab for a use case this group intended it for.

Let's move to addressing @vocab's usage. Considering both its benefits for developers and the security concerns raised. I agree with @tplooker that removing @vocab from the base context does not completely address the concerns in #1514, though if it can reduce some risk, I support it. I have approved #1525 towards this end.

[TallTed]

Assuming there's a suitable anchor, "described earlier in this section" should link back to that description.

[PatStLouis]

@tplooker
The issues you list are:

@vocab is very useful in certain cases

The only use case I've seen listed here over and over again is "issuers don't want to do json-ld while prototyping". If issuers don't want to bother using the technology they are using (this statement in itself highlights the irony of such use cases), they create issues downstream and should consider other options for their solution, at least momentarily. Or, like the solution proposed, segregate their use cases into a subset of credentials, issuer-dependent credentials. I've yet to see an absolute requirement of leveraging @vocab in conjunction with data integrity, if you have one in mind please share and I will be happy to re-consider.

Most JSON-LD processors already support it, so it’s difficult for an issuer to not support it without modification to underlying libraries.

This is a discussion about data integrity and the use of these features in conjunction with data integrity. If the goal is to address a change in the json-ld library, these conversations should happen elsewhere. The conversation happening here are about data integrity and the VC data model. Shifting the blame elsewhere is just a deflection to avoid addressing the responses people are making. Concrete solutions identified by your very own research are being proposed to address this specific concern.

We finally agree on something :) which is that @vocab allows one to maliciously redefine terms. Now whether that context be the core vcdm or otherwise we must fix the issue rather then just trying to avoid its usage in certain contexts, because that would be as I've said before just avoiding the problem. And if we do that then IMO we don't need to remove @vocab from the core context because its usage becomes safe.

I've always partially agreed with you since my first post and never claimed otherwise. Having dangled in pen-testing and cybersecurity in the past, I do find this disclosure valuable and have already demonstrated it in a few places for education purposes (while giving the credit to MATTR). Besides, removing @vocab from the base context is a tangible measure with minimal impact and a strong remediation to some of this concern.

What I do disagree with is labeling this as a vulnerability, as this is an attack vector, there is a difference. I'll play nice and say sure, you demonstrated a low impact vulnerability in a sandbox/development/experimental environment with said attack. There was no harmful impact and you only got a json response which says verified (which is true, because the signature is valid). No further treatment is made, this didn't give you access to any resources, you didn't exploit any system nor run any unauthorized code. If theoretically some measures were in place, the credential would still be verified with a warning of un-trusted context, so a business layer controller can make the proper decisions based on that validation response. This is surely something we can look into as we are currently evaluating verification responses in the vc-api, and what consists of an error and a warning. This has also been acknowledged as something to include in conformance testing. A reminder that the vc-api /credentials/verify endpoint is meant to be an internal call, which request/response is meant to be pre/post processed. Providing this interface directly is only for example/demonstration/development/test-suites use cases. The vcplaygroud allows anyone to throw garbage input.

As an aside, here's a vulnerability that was reported in the QC covid passport verification app. This is a vulnerability describing how you could forge a proof of vaccination of any provincial resident. It was demonstrated using the production ready available mobile wallet app and verification software. Sure, covid circumstances were different as a lot of technology had to be put out quickly, but the service providers were using jwt (smart health card) and did a bad implementation leading to this vulnerability. Is jwt to blame here? No one is making this claim, it's the implementation which is the issue. Here's a blog post about the vulnerability a friend of mine wrote.

[PatStLouis]

@decentralgabe

I also apologize if my word choices are interpreted negatively. There are significant claims being made here and surely this will tense up the discussions and create a division, however I can assure you I'm not looking to make any negative assumptions about your professional qualifications or work ethics. I don't know you besides a few posts I've read notably around did:x or maybe a talk at IIW, and I surely don't know what conversations you have with your clients, nor is it any of my business. What I do assume due to your dedication in the space is that you have a good grasp on what is at stake and have the ability to think critically, as you've demonstrated.

In the original issue (#953), a primary motivation was lowering the barrier to entry for developers new to JSON-LD, enabling them to create valid Verifiable Credentials more easily. My advocacy for keeping @vocab aligns with this goal of maintaining accessibility for a broader range of implementers.

I do appreciate the motivation, however I will have to say, as a developer, I've seen many good intentions of "we'll fix it later" that never leads to anything once the temporary fix "works". Maybe your experiences can tell a different story. The solution proposed also keeps this available, whilst giving a nudge to developers to take action on it downstream. I've also advocated the @vocab feature while assessing solutions during procurement processes, however these were at the prototyping stage and was only a shortcut to claim conformance. I was also making sure to provide sufficient warning to address this as the solution reaches closer to pilot/production stages. When helping companies adopt the technology, its your primary goal to help them, not gate keep them. Using @vocab is great at this when time is an issue, but it's important for the implementers relying on this feature early not to become complacent.

The idea of having a separate url for this use case, which can simply be replaced with a proper context url once the implementers did the work, was never refuted by anyone. This is a simple, elegant solution that would greatly reduce the friction we are seeing here.

I also use the @vocab feature to catch any terms I didn't properly defined while prototyping credentials, helping me review context files.

The @vocab feature now seems to be partially used as supporting evidence to request a stop to the data integrity work which is not something I like to see in this community.

Removing it from the base context at the very least makes it easier to manage its use case through spec text and requires implementers to take deliberate actions to enable it (adding the issuer-dependent url to the context). It also provides information to verifiers who also do not want to do json-ld that this credential contains issuer-dependent terms.

The risks around @vocab can then be re-evaluated once this action is taken.

[tplooker]

The only use case I've seen listed here over and over again is "issuers don't want to do json-ld while prototyping". If issuers don't want to bother using the technology they are using (this statement in itself highlights the irony of such use cases), they create issues downstream and should consider other options for their solution, at least momentarily. Or, like the solution proposed, segregate their use cases into a subset of credentials, issuer-dependent credentials. I've yet to see an absolute requirement of leveraging @vocab in conjunction with data integrity, if you have one in mind please share and I will be happy to re-consider.

I wouldn't frame this usecase as "issuers don't want to do json-ld while prototyping", even if you don't define your own JSON-LD context, but you are still issuing or verifying a JSON-LD based VC, you are "doing json-ld".

For example more generally I would say a website that integrates in JSON-LD following googles guidelines for SEO is "doing json-ld" even though they aren't defining their own @context instead just using schema.org.

In fact the most promising direction for this technology is to actually limit the situations whereby someone has to define their own @context, many issuers should ideally share @context entries to limit the number of different context files an ecosystem needs to collectively trust. With regard to @vocab support in the core context I personally believe this follows this objective further, issuers who simply just want to use a single fixed namespace can without having to bring in seperate context files, that in itself is a use case.

However as I've said earlier in the thread I won't block removal of this from the core context but I will just re-state for the record this does nothing to fix the identified issue it is linked to, it simply avoids fixing the problem.

[msporny]

@tplooker wrote:

this does nothing to fix the identified issue it is linked to, it simply avoids fixing the problem

It seems that others in this thread, and in the WG, disagree. This PR is part of a broader solution that is being discussed in w3c/vc-data-integrity#272.

"avoids" can be interpreted as a belief that people are "uninformed" at best or "acting in bad faith" at worst (putting their heads in the sand instead of dealing with an issue).

"problem" ignores the very long thread of discussion that proposes that the "real problem" was a misconfiguration of software in the security disclosure. I realize that both of these points are some of the points of contention in that very long thread, but repeating one side of that point of contention doesn't accomplish much when it is clear that there is disagreement on "avoiding" and "problem" in the w3c/vc-data-integrity#272 thread. On the contrary, the issue has had vigorous debate and this PR was one of the outcomes of that debate.

Let's try to keep discussion in this thread focused on this specific PR and its changes and keep the more general discussion on "what else to do" in w3c/vc-data-integrity#272.

[dmitrizagidulin]

👍

[iherman]

The issue was discussed in a meeting on 2024-07-17

• no resolutions were taken

View the transcript

3.2. Remove @vocab from the base context. (pr vc-data-model#1520)

See github pull request vc-data-model#1520.

Brent Zundel: also talking about #1525 simultaneously.

Brent Zundel: 1520 and 1525 exist as a pair, really.

See github pull request vc-data-model#1525.

Brent Zundel: One of them 1520 takes vocab out of base context. 1525 adds optional new context with vocab in it.
… which allows people to test/develop.

Dmitri Zagidulin: quick question. about adding vocab to undefined terms context. Is that an option in addition to the examples context?
… we already have @vocab in the examples.
… I am a fan of taking it out of core.

Manu Sporny: You're right, Dmitri. 1525 would add a separate @vocab in the undefined terms context.
… that one would be able to be used in production for those who want to use it. We recommend not to use @vocab in production unless you know what you're doing.
… the compromise we got to was that Gabe wanted something other than the examples contexts that leverages issuer-defined terms.
… Gabe liked this approach, so it met his concerns.
… The main difference is that the examples context is not for production.
… The new one is.

Michael Jones: I take exception that the working group has decided to remove @vocab.

Brent Zundel: I did not see it that way, so I didn't call it out as chair.
… ok. two PRs. anyone other than Mike who objects, please speak up.

Brent Zundel: as the only objector, is this is merged in, do you expect to formally object if this goes in.

Michael Jones: I hope we'll never get there.
… We should have stability. This is destabilizing.
… The reason we put this in is so that all terms are processed as RDF. This is a security problem.

Brent Zundel: I felt there was additional information that justified reopening the discussion.
… I agree it is destabilizing, but I felt it was necessary.

Michael Jones: this is a security degradation.

Ivan Herman: +1 to dmitriz.

Manu Sporny: +1 to dmitriz.

Dmitri Zagidulin: Just taking out @vocab is destabilizing, but adding it back to undefined terms to restore stability.

Benjamin Young: +1 to dmitriz; definitely makes things clearer for everyone.

Dmitri Zagidulin: we are offering the same security options, we're just adding a flag for it.

Michael Jones: it's still a security degradation because its still optional.
… developers are lazy.
… deployments will occur where they forget to add the additional context.

Ivan Herman: I'm surprised by "security degradation". But the current situation has a security problem as well.
… so the question is which of these are worse?

Manu Sporny: I also take exception to the concept that there is a security degradation.
… we are repeating things that have been discussed in the issues multiple times.
… If a term is undefined, the processor throws an error. That's what happens. I don't see how a processor throwing an error is a security degradation.
… This is a security enhancement.
… You seem to be arguing from a position from a year ago that we have already addressed.

Dmitri Zagidulin: +1 I like that suggestion.

Brent Zundel: I believe I have a suggestion for addressing Mike's concern. How about "If you define terms that are not in the default context, you must use the undefined terms context".

Joe Andrieu: The only concern I have with what you said, Brent, is that you should still be able to define terms in our own context and not use the undefined terms context.

Joe Andrieu: +1.

Brent Zundel: You must either define terms in your own context or use the undefined terms context.

Ivan Herman: +1 to brent's option.

Dave Longley: +1 to say that you must do either of these things.

Brent Zundel: does this sound like a viable path forward?
… I'm seeing +1s.
… anyone who can't live with this moving forward, speak now.
… This feels like consensus emerging.
… Manu, these are your PRs, will you make those mods?

Manu Sporny: yes.
… can we merge it once we do that?

Brent Zundel: Mike?

Michael Jones: I'd like to get a few people's eyes on the new semantics before we merge it.

Brent Zundel: Manu, thanks for the willingness to make the changes. Ping me or Mike once you have the changes in.
… If those changes go in this afternoon, can you re-review by the end of the week?

Michael Jones: Yes.

Brent Zundel: So we'll have feedback by Friday, which if cleared, means you can merge.
… one last thing on charter. We don't need to hold off on a bunch of PRs as the charter explicitly includes the details we need.
… next up: Issues.

[msporny]

From the telecon today:

Brent Zundel: You must either define terms in your own context or use the undefined terms context.

This has been implemented in the PR, in these lines.

Requesting a re-review from @selfissued.

Per the call today, this PR will be merged by Friday if there are no more objections.

[msporny]

Normative, multiple reviews, changes requested and made, no remaining objections, WG-imposed merge delay requirement met, merging.