Attempt to converge format/selection in verifiable_presentations with presentation_submission

[Daniel Buchner]

David Waite noticed something that could really help convergence of the specs and simplify the interplay between PE Submission objects and the verifiable_presentations in the OIDC spec. I have added examples of the present vs proposed below, but the key difference is we would no longer need to separate conventions for format expression of the various layers, and can reuse the exact same logic that doesn’t assume any particular layer depth. Let me know what you think.

Current OIDC PR example:

{
  "iss": "https://self-issued.me/v2",
  "aud": "https://book.itsourweb.org:3000/client_api/authresp/uhn",
  "iat": 1615910538,
  "exp": 1615911138,
  "sub": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
  "sub_jwk": {
    "kty": "RSA",
    "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx...DKgw",
    "e": "AQAB"
  },
  "auth_time": 1615910535,
  "nonce": "960848874",
  "verifiable_presentations": [
    {
      "format": "ldp_vp",
      "presentation": {
        "@context": [
          "https://www.w3.org/2018/credentials/v1"
        ],
        "type": [
          "VerifiablePresentation"
        ],
        "verifiableCredential": [
          {
            "@context": [
                "https://www.w3.org/2018/credentials/v1",
                "https://www.w3.org/2018/credentials/examples/v1"
            ],
            "id": "https://example.com/credentials/1872",
            "type": [
                "VerifiableCredential",
                "IDCardCredential"
            ],
            "issuer": {
                "id": "did:example:issuer"
            },
            "issuanceDate": "2010-01-01T19:23:24Z",
            "credentialSubject": {
                "given_name": "Fredrik",
                "family_name": "Strömberg",
                "birthdate": "1949-01-22"
            },
            "proof": {...}
          }
        ],
        "id": "ebc6f1c2",
        "holder": "did:example:holder",
        "presentation_submission": {
          "id": "Selective disclosure example presentation",
          "definition_id": "Selective disclosure example",
          "descriptor_map": [
            {
              "id": "ID Card with constraints",
              "format": "ldp_vc",
              "path": "$.verifiableCredential[0]"
            }
          ]
        },
        "proof": {...}
      }
    }
  ]
}

Proposed convergence that allows us to use the same existing mechanism for both format expression and cred selection:

{
  "iss": "https://self-issued.me/v2",
  ...
  "verifiable_presentations": [
    {
      "presentation_submission": {
        "id": "Selective disclosure example presentation",
        "definition_id": "Selective disclosure example",
        "descriptor_map": [
          {
            "id": "ID Card with constraints",
            "format": "ldp_vp",
            "path": "$.presentation",
            "path_nested": {
              "format": "ldp_vc",
              "path": "$.verifiableCredential[0]"
            }
          }
        ]
      },
      "presentation": {
        "@context": [
          "https://www.w3.org/2018/credentials/v1"
        ],
        "type": [
          "VerifiablePresentation"
        ],
        "verifiableCredential": [
          {
            "@context": [
                "https://www.w3.org/2018/credentials/v1",
                "https://www.w3.org/2018/credentials/examples/v1"
            ],
            "id": "https://example.com/credentials/1872",
            "type": [
                "VerifiableCredential",
                "IDCardCredential"
            ],
            "issuer": {
                "id": "did:example:issuer"
            },
            "issuanceDate": "2010-01-01T19:23:24Z",
            "credentialSubject": {...},
            "proof": {...}
          }
        ],
        "id": "ebc6f1c2",
        "holder": "did:example:holder",
        "proof": {...}
      }
    }
  ]
}

‌

[Daniel Buchner]

This Issue is in reference to the examples found in PR 44: openid / connect / Pull Request #44: Add presentation submission support — Bitbucket

[Jeremie Miller]

This looks much cleaner and at least for me logically parses well.

[Kristina Yasuda]

I really do not understand how RP is supposed to know the format of a VP if it is inside the VP itself. especially if it is a Base64url encoded vp-JWT

[Kristina Yasuda]

I think I misunderstood and the proposal is to externalize presentation_submisson and include it in the ID token - so it can help identify format of both vp and vc. If are to use presentation_submission, this does look like a cleaner way.

[Torsten Lodderstedt]

The current proposal in the PR follows the way WACI uses presentation submissions and was also the result of a discussion in the DIF credential WG Slack channel.

What is the benefit of your proposal?

Also note: your proposal is the first example of a presentation submission referring to a VP instead of a VC. I‘m surprised this is possible.

[Daniel Buchner]

“your proposal is the first example of a presentation submission referring to a VP instead of a VC. I‘m surprised this is possible.” - this is something the spec already provided for, because some exchanges we saw had multiple levels of wrapping (VPs wrapping at depth, and even tokens with VPs in them with VC children). The relevant section is here: DIF Presentation Exchange (identity.foundation). This was done to provide a singular, deterministic way to drill down through any number of layers and process layers by format (e.g. when you need to know the format at a layer to decode it, in the case of Base64Url encoded blobs).

The advantage here is that we would be able to use the exact same format indicator and mapping utility that handles all the format indicators in one place, simplifying the spec and implementations (imo). Doing this would allow a PE library to just handle this without any difference in processing across envelope transport protocols.

[Torsten Lodderstedt]

ok. thanks for the explanation.

A further advantage of your proposal is that the verifier can determine metadata about JWT based VCs before base64url decoding them.

Moreover, this keeps PE syntax outside of the presentation object. When implementing the current approach, we run into problems with existing formats and frameworks. So the proposal would solve this as well.

However, we would loss the cryptographic protection of the presentation submission in some situations, e.g. when using vp tokens and in unsigned userinfo responses. I’m not sure how important this is, but Orie pointed it out as an advantage of embedding the presentation submission into the presentation (as WACI does).

Any thoughts?

[Kristina Yasuda]

this is addressed by PR #44 and will be closed when it is merged

[Kristina Yasuda]

We can close this issue in the next SIOP call since following the discussions in DIF-OIDF calls, the agreement has been reached to include presentation_submission in the ID Token to be able to refer to both VP and VC sent in the response as defined in section 6.2 of OIDC4VP

Also example below:

{
   "iss":"https://self-issued.me/v2",
   "aud":"https://client.example.org/cb",
   "iat":1615910538,
   "exp":1615911138,
   "sub":"NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
   "auth_time":1615910535,
   "nonce":"n-0S6_WzA2Mj",
   "sub_jwk": {
     "kty":"RSA",
     "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
     4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
     tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
     QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
     SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
     w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
     "e":"AQAB"
    }
    "_vp_token_": {
        "presentation_submission": {
            "id": "Selective disclosure example presentation",
            "definition_id": "Selective disclosure example",
            "descriptor_map": [
                {
                    "id": "ID Card with constraints",
                    "format": "ldp_vp",
                    "path": "$",
                    "path_nested": {
                        "format": "ldp_vc",
                        "path": "$.verifiableCredential[0]"
                    }
                }
            ]
        }
    }
}

‌

‌

[Kristina Yasuda]

Resolving since this issue has been addressed by deciding to put presentation_submission in the ID Token.

However new issue has been raised whether presentation_submission itself should be optional - Issue #1364