Optionality: What happens when processors don't honor constraints?

[bumblefudge]

Broken out from a review comment on 287. Assigning to @nklomp as per today's call

[nklomp]

Feature are introduced as extended functionality, then the spec mentions 'Processing entities are not required to support Feature'.

It does not go into detail about what can happen if a holder doesn't support these features. This is not applicable to verifiers as they typically are in control about the definition.

Typically a too broad submission from the processing entity is okay, but there is no guarantee right? For instance when the definition contains certain additional constraint features, like submission requirements, same_subject or subject_is_issuer. If the processing entity is not aware of that feature, the verifier should reject the submission if it does not pass these constraints.

Suggest to add some wording to the feature introduction pointing this out. Something to the extend of:

[[ref:Verifiers]] that are using [[ref:Features]] that a processing entity does not support, might result in submissions that can be rejected by the respective [[ref:Verifiers]]. This is especially the case when a feature introduces additional constraints on the [[ref:Input Descriptor Object]], like for instance the [Relational Constraint Feature](#relational-constraint-feature), where thesubject_is_issuerproperty could be used by a [[ref:Verifier]] to require that certain inputs be _self_attested_. Depending on the [[ref:Verifier]] implementation a submission which is not self attested might be rejected, because the processing entity is not aware of the requirement the [[ref:Feature]] introduced.

[csuwildcat]

Closed by PR #333