[OpenID-Specs-eKYC-IDA] Issue #1188: Embedded liability implications in the framework? (openid/ekyc-ida)

[sgmouy]

New issue 1188: Embedded liability implications in the framework?
https://bitbucket.org/openid/ekyc-ida/issues/1188/embedded-liability-implications-in-the

sgmouy:

I am a bit concerned that the framework has embedded liability implications for OPs – meaning that OPs are viewed or understood to ‘guarantee’ the trustworthiness of claims and therefore triggering recourse in the event that, for any reason, they happen not to be true. This may possibly be a desirable outcome in some situations, but I believe not for the overwhelming majority of use cases.  

To take an example, I suspect very few financial institutions will readily agree to ‘commit’ to any statement regarding the level of assurance of any data communicated – why should they if potential liability is attached to this?

The main reason for my concern is threefold:

* One is that the terminology used leads to that conclusion: for example, Ops ‘attest’ to certain factual elements \(‘attest’ means ‘to affirm to be true or genuine’\) towards ‘Relying parties’, so that these can ‘rely’ on those elements. Claims are ‘verified’ but since the only known party involved is the OP, the logical conclusion must be that they are so verified by the OP.

* In addition, the contemplated choice of trust frameworks only offers limited, if any, relief in this respect. For example, stating that a claim is verified pursuant to say German \(or for that matter any other national\) AML regulations is of extremely limited assistance to the OP vis a vis the RP in the \(very unfortunate\) event where the claims happens to be untrue – how in practice is this going to help the OP get off the hook?;

* Last but not least, as I understand it, there is no separate contractual arrangement between the OP and the RP that could include tailored liability provisions. I am not suggesting you should have these in place – this would hugely complicate deployment processes – but it means that in the event of litigation, all that could be looked at the OpenID Connect specifications we are now discussing.

I completely agree that the framework should be neutral when it comes to liability implications. At the same time, if one is talking about ‘Verified Claims’ about natural persons ‘in compliance with certain laws’, one should acknowledge that liability implications are bound to be considered – this is inherent to the purpose of a framework where relying parties can ‘rely’ on crucial datasets provided by other parties - especially when RPs are insisting on LoAs higher than Low or data more robust than self-declaratory information. In short, it is unrealistic, even delusional, to view this as a non-issue. There is no escape from it.  

Maybe the way forward could be to offer a menu of liability options, ranging from ‘full recourse to the OP’ \(not popular with OPs\) to ‘transmitted AS IS’ \(meaning no recourse whatsoever to the OP, but not great for RPs\) and ‘subject to separate liability agreement’ \(better but very cumbersome to put in place\).

Another possibility would be to consider a specific ‘mid-range’ situation, such as for example a Substantial LoA eIDAS Eid, where the dataset is viewed as robust but certainly not fool-proof, therefore leaving scope for false negatives. \(Incidentally, this is the threshold identity proofing level for AML regulations in many countries, including France\). We could then consider what is expected – and not expected – from the OP for those, and model the RP recourse accordingly.

Your views on this would be appreciated.