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

Ivan Kanakarakis ivan.kanak+openid_ekyc_ida at gmail.com
Mon Feb 24 13:24:32 UTC 2020

Hello everyone,

On Thu, 20 Feb 2020 at 15:48, Marcos Sanz via Openid-specs-ekyc-ida
<openid-specs-ekyc-ida at lists.openid.net> wrote:
> Dear all,
> this is also one of our oldest open tickets
> https://bitbucket.org/openid/ekyc-ida/issues/1094/how-to-treat-unknown-identifiers-in-claims
> and a PR to fix it
> https://bitbucket.org/openid/ekyc-ida/pull-requests/10/op-reaction-to-unknown-query-restrictions/diff
> 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?

In general, my preference is clearly (A). I would always choose
evolvability. Having said this, you mention that:

> OTOH the RP doesn't have a clue why it got an empty answer

which is true, but which also indicates that it may need a way to
figure this out. There are two way to fix this:

1. implicit: the empty answer indicates that this could not be
fulfilled. There is no information other than that. An empty answer
means that the request could not be fulfilled and the reason _may be_
that the OP does not understand/support the framework/evidence

2. explicit: define a structure to indicate that the request could not
be fulfilled (in a non-fatal way). The existence of that structure in
the response document means that _part_ of the request cannot be
fulfilled. A pointer to the part of the request that was not fulfilled
should be there, along with an error-code and an optional message with
specific details. Where this structure is placed in the response body,
if it replaces the "empty" part that we talk about, whether the
pointer is a real pointer or a copy of part of the request, and how
detailed a message should be; these are all part of the wider
discussion on the spec.


Ivan c00kiemon5ter Kanakarakis  >:3

More information about the Openid-specs-ekyc-ida mailing list