Skip to content
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

Framing on nested graphs #150

Open
stevenvegt opened this issue Mar 20, 2023 · 0 comments
Open

Framing on nested graphs #150

stevenvegt opened this issue Mar 20, 2023 · 0 comments

Comments

@stevenvegt
Copy link

Hi wonderful people from the JSON-LD Framing group!

I have a question regarding framing on nested JSON-LD data.

Background

My question is in relation to Verifiable Credentials. I'm a maintainer of an open source credential wallet. We are now starting with the implementation of the new OIDC4VCI which supports a flow where the Issuer can ask the Holder for proof of ownership of a credential (in the form of a presentation). This can be done by the DIF Presentation exchange. In there is a Future which allows the Relying Party to query by 'frame': https://identity.foundation/presentation-exchange/#json-ld-framing-feature.
This is I think so much more elegant than the json-schema filters. Since all of our credentials are in JSON-LD anyway, it seems the way to go. But I'm running into issues here.

Assumption

One can use JSON-LD framing to "query" over a set over credentials, stored as a list of graphs.

Problem

I would like to use framing to query a set of Verifiable Credentials. I made a simpler example to illustrate the problem:
Input:

{
  "@context":{
    "@vocab":"http://example.org#",
    "schema":"http://schema.org/"    
  },
  "@graph":[
    {
      "@type":["Type1", "Type2"],
      "schema:name":"John"
    },
    {
      "@type":["Type2"],
      "schema:name":"John"
    },
    {
      "@type":["Type1", "Type2"],
      "schema:name":"John",
      "schema:address": {
        "@id":"uri:1",
        "schema:street":"Oneway"
      }
    },
    {
      "@type":["Type1", "Type3"],
      "schema:name":"John",
      "schema:address": {
        "@id":"uri:2",
        "schema:street":"Middleroad"
      }
    }
  ]
}

I want to query for a "credential" of Type1, name is John and address with street Oneway:

Frame:

{
  "@context":{
    "@vocab":"http://example.org#",
    "schema":"http://schema.org/"
  },
  "@type": ["Type1"],
  "schema:name": "John",
  "schema:address":{
    "schema:street":"Oneway",
    "@requireAll": true
  },
  "@requireAll": true
}

This is the output I get from the JSON-LD Playground:

{
  "@context": {
    "@vocab": "http://example.org#",
    "schema": "http://schema.org/"
  },
  "@graph": [
    {
      "@type": [
        "Type1",
        "Type2"
      ],
      "schema:address": {
        "@id": "uri:1",
        "schema:street": "Oneway"
      },
      "schema:name": "John"
    },
    {
      "@type": [
        "Type1",
        "Type3"
      ],
      "schema:address": null,
      "schema:name": "John"
    }
  ]
}

As you can see, the address of the second entry is null. I expected the result not to have this entry at all. That is also what happens when I frame on @id:

Input on @id:

{
  "@context":{
    "@vocab":"http://example.org#",
    "schema":"http://schema.org/"
  },
  "@type": ["Type1"],
  "schema:name": "John",
  "schema:address":{
    "@id":"uri:1"
  },
  "@requireAll": true
}

Output:

{
  "@context": {
    "@vocab": "http://example.org#",
    "schema": "http://schema.org/"
  },
  "@type": [
    "Type1",
    "Type2"
  ],
  "schema:address": {
    "@id": "uri:1",
    "schema:street": "Oneway"
  },
  "schema:name": "John"
}

So my questions are:

  1. Is my assumption correct?
  2. What is the difference of framing by @id and framing by value?
  3. If this is the expected behavior, is framing the logical mechanism to use in the DIF presentation exchange?
  4. Could it be that there is an example missing from the spec which gives more clarity about framing in nested structures?

Thanks for taking the time to look at this issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Discuss-Call
Development

No branches or pull requests

1 participant