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

[Achim Schlosser]

Hi,


These are all fair points, but my understanding (and it’s the only viable approach here I think) is that the liability definition / guarantees life outside of the framework and should not be addressed here. These details are part of the definition / setup of the trust framework. 

In terms of your example:

eIDAS:

- approval of entities who are allowed to attest a substantial level identification is wholly separate process, BUT as a result of that process the entity (OP or others via aggregated/distributed claims) acquire a registered certificate that they will use as part of the eKYC login process to sign the tokens that they provide
- RPs can thus verify this trust-anchor independently and do not rely on this specification to do so. 

Similar mechanisms should be available for any trust framework and RPs need to be aware of them to verify the trust anchor on which the attestation is based. If that is not obvious it might need to be make more explicit in the spec..

The liability is always with the OP here at first, where it’s the RPs liability to check the correctness and maybe other things depending on regulatory needs.  I don’t see a means of customizing that in any way because it's all defined in the trust framework. 


Best

Achim  



On 26.03.20, 16:39, "Openid-specs-ekyc-ida on behalf of sgmouy via Openid-specs-ekyc-ida" <openid-specs-ekyc-ida-bounces at lists.openid.net on behalf of openid-specs-ekyc-ida at lists.openid.net> wrote:

    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.
    
    
    -- 
    Openid-specs-ekyc-ida mailing list
    Openid-specs-ekyc-ida at lists.openid.net
    http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida