[OpenID-Specs-eKYC-IDA] On robustness and extensibility

Marcos Sanz sanz at denic.de
Thu Feb 20 13:48:14 UTC 2020

Dear all,

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 mailing list