Present‑Proof v2 (DIF) fails to match W3C LDP VC; /records/{id}/credentials empty; send‑presentation yields empty VP + verified=false

[nodlesh]

Summary
We’re seeing ACA‑Py Present‑Proof v2 (DIF) fail to match a W3C LDP VC that is clearly present in the holder wallet. /present-proof-2.0/records/{pres_ex_id}/credentials returns [], and even when we force dif.record_ids using the wallet record_id or issuance cred_id_stored, the holder still sends an empty Verifiable Presentation (verifiableCredential: [], descriptor_map: []) and the verifier ends in state=done, verified=false. We previously considered dropping schema matching but that will result in issue #4006 , so we currently have no workable workaround.

Environment

• ACA‑Py: 1.4.0
• Wallet: Askar
• Protocols: issue‑credential v2 (ld‑proof) + present‑proof v2 (DIF)
• Two internal ACA‑Py agents (holder + verifier), same Docker Compose stack
• --auto-respond-presentation-request disabled; we call send-presentation explicitly

Credential (from /credentials/w3c)
Example record (sanitized):

• record_id: 941fd068c88645a5a1594c32116af550
• expanded_types:
  • https://www.w3.org/2018/credentials#VerifiableCredential
  • https://schema.affinidi.io/AyraBusinessCardV1R0.jsonld
• proof_types: Ed25519Signature2020
• credentialSchema.id: https://schema.affinidi.io/AyraBusinessCardV1R0.json
• type: ["VerifiableCredential","AyraBusinessCard"]
• schema_ids: []

Presentation Definition (verifier request)

{
  "name": "Ayra Business Card LDP",
  "purpose": "Present an Ayra Business Card signed as a Linked Data Proof VC",
  "format": { "ldp_vp": { "proof_type": ["Ed25519Signature2020"] } },
  "input_descriptors": [{
    "id": "ayra-business-card",
    "purpose": "Must be an Ayra Business Card with Ed25519Signature2020",
    "schema": [
      { "uri": "https://schema.affinidi.io/AyraBusinessCardV1R0.jsonld#AyraBusinessCard" },
      { "uri": "https://schema.affinidi.io/AyraBusinessCardV1R0.jsonld" },
      { "uri": "https://schema.affinidi.io/AyraBusinessCardV1R0.json" },
      { "uri": "https://www.w3.org/2018/credentials#VerifiableCredential" }
    ],
    "constraints": {
      "fields": [
        { "path": ["$.type","$.vc.type","$.credential.type"], "filter": { "type": "array", "contains": { "const": "AyraBusinessCard" } } },
        { "path": ["$.proof.type","$.proof[0].type"], "filter": { "type": "string", "const": "Ed25519Signature2020" } }
      ]
    }
  }]
}

Steps to Reproduce

1. Issue a W3C LDP VC (issue‑credential v2) to the holder.
2. Confirm VC exists in holder wallet via /credentials/w3c (record shown above).
3. Verifier sends present‑proof v2 request with Presentation Definition above (DIF).
4. Holder checks /present-proof-2.0/records/{pres_ex_id}/credentials → returns [].
5. Holder calls /present-proof-2.0/records/{pres_ex_id}/send-presentation with:

   { "auto_remove": false, "dif": { "record_ids": { "ayra-business-card": ["<wallet record_id>"] } } }
   

6. Verifier calls verify‑presentation.

Observed

• Holder sends VP with verifiableCredential: [] and descriptor_map: [].
• Verifier record ends in state=done, verified=false.
• This is consistent whether we use:
  • wallet record_id from /credentials/w3c, or
  • cred_id_stored from issue‑credential v2 record.

Expected

• ACA‑Py should match the wallet credential to the PD.
• /present-proof-2.0/records/{pres_ex_id}/credentials should return candidates.
• VP should contain the VC and verifier should return verified=true.

Attempts / Workarounds

• Disabled holder auto‑respond; explicit send‑presentation with record_ids.
• Used wallet record_id and issuance cred_id_stored as record_ids.
• Adjusted schema URIs (fragment/no‑fragment, JSON/JSON‑LD).
• Restrict proof_type to single suite (Ed25519Signature2020).
• Tried VC v1 context experiment; still verified=false.
• Dropping schema matching might allow selection, but is impacted by present-proof v2 (DIF) crashes when input_descriptor.schema is omitted (NoneType uri_groups) #4006 (schema requirements) → no stable workaround.

Questions / Guidance Needed

1. For DIF present‑proof v2, which ID should dif.record_ids use for W3C LDP credentials: wallet record_id, cred_id_stored, or something else?
2. How does ACA‑Py populate schema_ids for W3C LDP? Our records show schema_ids: [] even though credentialSchema.id is present.
3. Should input_descriptors.schema be compared against credentialSchema.id, expanded_types, or something else?
4. Is there a known issue where /present-proof-2.0/records/{id}/credentials returns empty for LDP VCs?
5. Any recommended config or endpoint for DIF + LDP selection that avoids empty VP?

[nodlesh]

I was able to overcome the issues detailed above. I had my issuer set to did:sov with the --no-ledger flag on the agent. This caused most of the issues. Changing to did:key resulted in my proof getting verified.
Here are the specifics of what ACA-Py can and cannot do from my investigations:

• DIF/Present‑Proof v2 can verify LDP VCs when the issuer DID is did:key (no ledger).
• ACA‑Py can issue LDP credentials and verify them end‑to‑end once:
  • proof request uses OR schema matching (oneof_filter: true), and
  • we avoid proof‑path JSONPath constraints (proof filtering not supported).
• Candidate selection for DIF works only when schema/proof_type filters match, and it ignores constraints.fields (type/path filters don’t affect selection).

What doesn’t work / limitations we hit:

• Schema IDs aren’t stored for LDP VCs (schema_ids is empty), so schema‑based PD matching only works via “type URIs” or OR‑matching with oneof_filter.
• DIF selection ignores constraints.fields, so path filters (type/proof filters) don’t affect candidate selection.
• Proof‑path JSONPath on $.proof isn’t supported by ACA‑Py’s DIF handler and causes failures.

I have some extra debugging added to ACA-Py that allowed me to narrow my issue. I will do a PR with this added debugging.

[swcurran]

Thanks -- interesting stuff. We have work in planning towards the removal of Indy from the core and into plugins (see #3987) that includes things like the --no-ledger and will hopefully clean up that part of what you are seeing. Would definitely welcome more on the W3C LDP (or as they are now known, Data Integrity Proofs). Not sure who else is working on those right now.