Rethink nested Paths

[bellebaum]

I might need some guidance on the consumption of a presentation_submission.

Take the following example from the specification:

{
  "presentation_submission": {
    "id": "a30e3b91-fb77-4d22-95fa-871689c322e2",
    "definition_id": "32f54163-7166-48f1-93d8-ff217bdb0653",
    "descriptor_map": [
      {
        "id": "banking_input_2",
        "format": "jwt_vp",
        "path": "$.outerClaim[0]",
        "path_nested": {
          "id": "banking_input_2",
          "format": "ldp_vc",
          "path": "$.innerClaim[1]",
          "path_nested": {
            "id": "banking_input_2",
            "format": "jwt_vc",
            "path": "$.mostInnerClaim[2]"
          }
        }
      }
    ]
  }
}

According to this submission and §6.1, I should validate three nested elements with formats jwt_vp, ldp_vc and jwt_vc respectively, to find that the innermost element is the submission for the banking_input_2 as defined in the referenced presentation definition.

I have the following questions:

• Assume I require some freshness using a nonce as suggested in §5.2. Where would I expect such a nonce? Given the infinite nestability of paths, is there a minimum depth where it should be found (note that freshness of an inner element implies freshness of any outer element whose signature captures the inner element).
• I guess the outermost element should be signed by the holder of the credential, while the innermost element should be signed by some issuer attesting the claims, but who should be the originator of the inbetween elements? Does it even matter given that there is no way to specify this in a presentation definition?
• Why didn't the holder just copy the jwt_vc and include it directly in their jwt_vp?

Proposal

Unless there are good use cases against this, for which we can provide a comprehensive validation procedure, I propose to limit the scheme to at most a single nested path.

The inner element ("The credential") describes any claims being made about a subject, while the outer element ("The presentation") may serve as proof that the communicating entity is indeed the subject, usually via some proof of possession of a key involving a nonce.

[csuwildcat]

@bellebaum one of the primary motivating reasons for nesting was actually that some implementations we were seeing had two levels of nested, encoded objects, like JSON > JWT, or JWT > JWT, thus we wanted to provide a way to path into an encoded string in a way that told you want the string was and how to decode it, then proceed through it with a selector after decoding.

[bellebaum]

@csuwildcat This seems fine as long as all you are doing is decoding and accessing nested objects. However, this way of thinking needs to be combined with some semantic information in a suitable manner to make any meaningful statements about the resulting submission. For instance:

• If any/the last validation step within a decoding procedure ensures authenticity of the data and the data was issued by a trusted party, it is to be considered a trustworthy statement.
• If any element containes a predefined nonce, it can be considered a direct response to the request.
• If any/the first validation step within a decoding procedure ensures authenticity of the contained data and the data was signed by a key referenced within a contained element, the statements can be considered about the outer signing party.

Now consider a simple verifier parsing a submission. In the end they want specific guarantees, i.e. (usually)

An entity I trust made statement X about the entity I am communicating with.

Somehow the validation procedure needs to provide this guarantee. The current procedure in §6.1 does not provide a clear reduction of this goal to subroutines to be implemented by e.g. the Claim Formats, and as argued above it seems unclear how to ensure this.

What I would like is an algorithm that is given an indication of validation requirements such as whether to ensure the holder's control over its keys, freshness of a presentation, and a list of valid issuers, and suitably delegates requirements such as "check this nonce" or "consider these as acceptable signing parties" to the validation algorithms in accordance with the Claim Format Designations.

[kimdhamilton]

Decision on 7/21 to address this in the next version.

I've had some lingering concerns over nested paths for a while, but have not been able to articulate them. I think this issue is a good starting point from which to dig in, to see how we can improve nested paths (including whether a structural change is needed or just documentation). At the same time, we'll need time to adequately address this, which we think is beyond the scope for this version.

Thanks for raising this @bellebaum -- excellent description and analysis!

[bumblefudge]

To be discussed very soon!