Consider note distinguishing submitter/verifier and presentation-exchange implementer

[decentralgabe]

My read of the spec...

First, in Section 6.2

...that include a constraints object with a limit_disclosure property set to the string value required, ensure that the data submitted is limited to the entries specified in the fields property of the constraints object.

Second, in Section 8, bullet 3

If the constraints property of the Input Descriptor is present, and it contains a limit_disclosure property set to the string value required, ensure that any subsequent submission of data in relation to the candidate input is limited to the entries specified in the fields property.

In practice, this means do not include the issuer, issued at date, expiry date, or any signature unless specifically requested. Not only do verifiers need to be aware of all possible configurations of credentials across types to request certain properties, they also need to have high-trust in the implementer of their presentation exchange library...and the library of the wallet/tool the party from which they're requesting verifiable data.

This completely shifts the trust from the verifier to the implementer of Presentation Exchange, and/or the software of the responding party. If this is known & intended, it should be called out in the specification. I am imagining cases where the implementer of this specification is different from a verifying party, and there's room for abuse.

I could have a malicious implementation that....

• Makes up data....and if no proof is requested, this is a problem
• Ignores certain checks, like issuers, credential status, or expiration...and if these fields aren't requested, this is a problem
• Leaves out additional data (i.e. a path asks for "name" and I include "Satoshi" instead of "Satoshi Nakamoto")...and if the request isn't specific enough this is a problem

So, what do I suggest? At least an implementers guide, and at most consideration of auditing and certifying known implementations. The biggest risk I see is having a verifier not doing the processing themself, but instead trusting a wallet with a malicious implementation that returns 'spec-compliant' responses. The tradeoff here, is that if full claims are returned for limiting/filtering for the verifier, there is an argument that the limiting/filtering is completely useless and no privacy has been preserved.

Phrased more simply: unless you can do cryptographic checks yourself, you're gonna have a bad time.

[decentralgabe]

Could be already solved by Section 6.3.

[dtmcg]

to be addressed as part of an implementation guide