Ambiguity related to proof types in 0510

[TimoGlastra]

This is is related to the question I brought up during the WG call.

Let's say we want to receive the below VP. How should the format object look like?

{
    // .. fields omitted ..
    "type": ["VerifiablePresentation"],
    "verifiableCredential": [
        {
            // VC1 of type Ed25519Signature2018
            "type": ["VerifiableCredential"],
            "credentialSubject": {
                "id": "did:key:ed25519"
            },
            "proof": {
                "type": "Ed25519Signature2018"
            }
        },
        {
            // VC2 of type BbsBlsSignatureProof2020 derived from BbsBlsSignature2020
            "type": ["VerifiableCredential"],
            "credentialSubject": {
                "id": "did:key:bls12381g2"
            },
            "proof": {
                "type": "BbsBlsSignatureProof2020"
            }
        }
    ],
    "proof": [
        {
            // Proof1 of type Ed25519Signature2018, authenticates subject of VC1
            "type": "Ed255219Signature2018",
            "verificationMethod": "did:key:ed25519#ed25519"
        },
        {
            // Proof2 of type BbsBlsSignature2020, authenticates subject of VC2
            "type": "BbsBlsSignature2020",
            "verificationMethod": "did:key:bls12381g2#bls12381g2"
        }
    ]
}

I thought it would look more like the following:

{
  "options": {
    "challenge": "23516943-1d79-4ebd-8981-623f036365ef",
    "domain": "us.gov/DriversLicense"
  },
  "presentation_definition": {
    "input_descriptors": [ /* ... */ ], 
    "format": {
      "ldp_vc": {
        // supported VC types (also nested in VP)
        "proof_type": ["BbsBlsSignatureProof2020", "Ed25519Signature2018"]
      },
      "ldp_vp": {
        // supported VP types
        "proof_type": ["BbsBlsSignature2020", "Ed25519Signature2020"]
      }
    }
  }
}

However reading the current RFC state I interpet it as if it should look more like the json below. I think it misses some important information here because we map from two ldp_vp types to a total of 3 proof types divided over the VCs and VPs.

To me it seems weird to say BbsBlsSignature2020 but receive BbsBlsSignatureProof2020.

{
  "options": {
    "challenge": "23516943-1d79-4ebd-8981-623f036365ef",
    "domain": "us.gov/DriversLicense"
  },
  "presentation_definition": {
    "input_descriptors": [ /* ... */ ], 
    "format": {
      "ldp_vp": {
        "proof_type": ["BbsBlsSignature2020", "Ed25519Signature2020"]
      }
    }
  }
}

@llorllale @troyronda I'm not sure if I made it clear. I'll try to rephrase if not

[llorllale]

Relevant section of the spec.

@TimoGlastra

The spec unfortunately lacks clear descriptions on these identifiers. I raised this issue requesting clarification: decentralized-identity/presentation-exchange#214.

I'm not sure if the formats are composable (Orie seems to think so - see comment in linked issue) but this is not clear from the spec.

What I think is the safest way (within the bounds of AIP 2.0) to request these two credentials would be to have format like in the last example you showed:

"format": {
    "ldp_vp": {
        "proof_type": ["BbsBlsSignature2020", "Ed25519Signature2020"]
    }
}

And rely on having "limit_disclosure": "required" on one of the input_descriptors and the fact that currently we are targeting BBS+ as the sole scheme to enable selective disclosure. I admit we would rely on not-so-firm grounds & assumptions but otherwise see no clear way to request this with the spec as it is.

[troyronda]

@TimoGlastra

I thought it would look more like the following

This makes sense to me as well. The VC and VP proofs are independent properties.

To me it seems weird to say BbsBlsSignature2020 but receive BbsBlsSignatureProof2020 Regardless of the previous point, you would not expect to receive BbsBlsSigantureProof2020 in the VP, but rather in the VC.

e.g., ldp_vp = BbsBlsSignature2020 and ldp_vc = BbsBlsSigantureProof2020