Specification that codifies an inter-related pair of data formats for defining proof presentations (Presentation Definition) and subsequent proof submissions (Presentation Submission)
Suggest to create a non-normative paragraph directly after the introduction of features, describing that it makes sense for implementations to be doing feature detection, especially on features they do not support, For some features, like for instance subject_is_issuer or status checks, you know that a verifier will likely reject a submission. IMO it makes sense to encourage implementations to abort early in case they detect a feature they do not support and which is highly likely to result in a rejection. That protects the holder from submitting data which will be discarded anyway.
In https://github.com/decentralized-identity/presentation-exchange/issues/293 I brought up the problem that certain features not supported by a wallet might result in a verifier rejecting the submission.
Suggest to create a non-normative paragraph directly after the introduction of features, describing that it makes sense for implementations to be doing feature detection, especially on features they do not support, For some features, like for instance subject_is_issuer or status checks, you know that a verifier will likely reject a submission. IMO it makes sense to encourage implementations to abort early in case they detect a feature they do not support and which is highly likely to result in a rejection. That protects the holder from submitting data which will be discarded anyway.