[OpenID-Specs-eKYC-IDA] On robustness and extensibility
sanz at denic.de
Thu Feb 20 13:48:14 UTC 2020
this is also one of our oldest open tickets
and a PR to fix it
I'll summarize it for you: the open question at the moment is how should
the OP react to a query where the RP specifies it wants verified_data
for a given trust_framework or by means of a certain evidence
type/method, BUT the OP doesn't understand/support the given value of
the framework/evidence type/method. The two alternatives at the moment are:
A) Omit the whole verified_claims element in the response. It's robust
and allows for extensibility in the classical sense of "ignore what you
don't understand". It also aligns OP behavior with the case when a
constraint is understood, but it cannot be fulfilled. OTOH the RP
doesn't have a clue why it got an empty answer.
B) Return the always-handy invalid_request error with an optional
error_description element about the unknown value in the request. It
gives the RP more information about what went wrong, RP can react
accordingly (e.g. repeat the request with another/no constraint). It can
make interoperability, e.g. within federations, more brittle though.
What do you think? Any other advantages/disadvantages we haven't thought
of? What's your preference?
More information about the Openid-specs-ekyc-ida