Skip to content

IRIs are terms can be misdefined #155

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

Closed
gkellogg opened this issue Mar 29, 2019 · 2 comments
Closed

IRIs are terms can be misdefined #155

gkellogg opened this issue Mar 29, 2019 · 2 comments
Assignees
Labels
propose closing satisfied Requirement Satisfied security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. spec:bug spec:enhancement spec:substantive

Comments

@gkellogg
Copy link
Member

JSON-LD provided no real limits on what can be defined as term. In fact, it's possible to define either a Compact IRI or an absolute IRI as a term which maps to something completely different, which is likely a security problem.

This needs to be fixed in JSON-LD 1.1 and marked as an errata for JSON-LD 1.0.

Consider the following document:

{
  "@context": {
    "schema": "http://schema.org/",
    "foaf": "http://xmlns.com/foaf/0.1/",
    "foaf:name": {"@id": "schema:name"},
    "http://xmlns.com/foaf/0.1/Person": {"@id": "schema:Person"}
  },
  "@type": "http://xmlns.com/foaf/0.1/Person",
  "foaf:name": "Danbri"
}

This actually expands to the following:

[
  {
    "@type": [
      "http://schema.org/Person"
    ],
    "http://schema.org/name": [
      {
        "@value": "Danbri"
      }
    ]
  }
]

The syntax document needs to place restrictions on terms which are compact IRI or absolute IRIs that they either do not include @id in their definition, or that it expand to the same IRI as if there was no @id present. A term looking like a compact IRI without a corresponding prefix definition would be treated as an absolute IRI.

Moreover, context processing should reject any term which looks like an absolute IRI (e.g., http://xmlns.com/foaf/0.1/Person above), as it opens another corner-case when compacting and no term is available to match the value to be compacted, which falls back to use the absolute IRI, but if that's defined as a term, it will be incorrect.

Given the following input document:

{
  "@context": {
    "schema": "http://schema.org/",
    "foaf": "http://xmlns.com/foaf/0.1/"
  },
  "@type": "http://xmlns.com/foaf/0.1/Person",
  "foaf:name": "Danbri"
}

and the following context:

{
  "@context": {
    "schema": "http://schema.org/",
    "foaf": "http://xmlns.com/foaf/0.1/",
    "foaf:name": {"@language": "de"},
    "http://xmlns.com/foaf/0.1/name": {"@language": "en"}
  },
  "@type": "http://xmlns.com/foaf/0.1/Person",
  "foaf:name": "Danbri"
}

The result will be

{
  "@context": {
    "schema": "http://schema.org/",
    "foaf": "http://xmlns.com/foaf/0.1/",
    "foaf:name": {
      "@language": "de"
    },
    "http://xmlns.com/foaf/0.1/name": {
      "@language": "en"
    }
  },
  "@type": "foaf:Person",
  "http://xmlns.com/foaf/0.1/name": "Danbri"
}

But, as "http://xmlns.com/foaf/0.1/name is defined to have @language: en, expanding this won't get back to the original, it will add @language: en to the "Danbri" value object.

[
  {
    "@type": [
      "http://xmlns.com/foaf/0.1/Person"
    ],
    "http://xmlns.com/foaf/0.1/name": [
      {
        "@language": "en",
        "@value": "Danbri"
      }
    ]
  }
]
@gkellogg
Copy link
Member Author

Reported in https://lists.w3.org/Archives/Public/public-rdf-comments/2019Apr/0000.html and added as an erratum in https://www.w3.org/2001/sw/wiki/JSON_LD_Errata.

@gkellogg gkellogg self-assigned this Apr 23, 2019
gkellogg added a commit that referenced this issue Apr 23, 2019
…pand to something other than they key itself.

Note, this represents a change from 1.0 behavior.

For #155.
gkellogg added a commit to w3c/json-ld-api that referenced this issue Apr 24, 2019
gkellogg added a commit that referenced this issue Apr 24, 2019
…pand to something other than they key itself.

Note, this represents a change from 1.0 behavior.

For #155.
gkellogg added a commit to w3c/json-ld-api that referenced this issue Apr 24, 2019
@azaroth42
Copy link
Contributor

CLosing, handled in latest specs per #166

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
propose closing satisfied Requirement Satisfied security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. spec:bug spec:enhancement spec:substantive
Projects
None yet
Development

No branches or pull requests

2 participants