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

Richard Backman, Annabelle richanna at amazon.com
Fri Mar 27 18:52:59 UTC 2020


IANAL, but won’t any language in the spec regarding liability be superseded by local regulations and whatever contract exists between the OP and RP, be it explicitly via individual agreements or explicitly via the OP’s Terms of Service? Is there any precedent for an Internet standard holding any legal weight?

That said, a guarantee of some sort seems to me to be intrinsic to the concept of a “verified claim.” OPs that aren’t willing to accept any liability regarding verified claims probably shouldn’t be issuing them. Why would an OP issue verified claims if it isn’t willing to stand by them? What value would those be to the RP? Isn’t a verified claim without a guarantee just a “claim”?

—
Annabelle Backman (she/her)
AWS Identity

> On Mar 27, 2020, at 9:57 AM, Anthony Nadalin via Openid-specs-ekyc-ida <openid-specs-ekyc-ida at lists.openid.net> wrote:
> 
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> Liability should be totally out of scope, all legal issues should be out of scope
> 
> -----Original Message-----
> From: Openid-specs-ekyc-ida <openid-specs-ekyc-ida-bounces at lists.openid.net> On Behalf Of Torsten Lodderstedt via Openid-specs-ekyc-ida
> Sent: Friday, March 27, 2020 9:52 AM
> To: Stephane Mouy <sgmouy at stephanemouy.com>
> Cc: Torsten Lodderstedt <torsten at lodderstedt.net>; OpenID eKYC Identity Assurance Working Group <openid-specs-ekyc-ida at lists.openid.net>
> Subject: [EXTERNAL] Re: [OpenID-Specs-eKYC-IDA] Issue #1188: Embedded liability implications in the framework? (openid/ekyc-ida)
> 
> 
> 
>> On 27. Mar 2020, at 17:37, Stephane MOUY <sgmouy at stephanemouy.com> wrote:
>> 
>> Well, identifying the problem is one thing, finding a definitive and readily deployable solution is quite another (as we can see with the Covid-19 epidemic).
>> 
>> One option is do nothing and leave this matter for OPs to consider what it implies for them. This is of course the simplest course of action, but I suspect it will lead many OPs, especially from the financial sector, thinking twice about attesting anything given the embedded liability bias of the framework, especially if there is a higher LoA involved - I would personally not recommend it to an OP unless it happens to be a KYC service provider and is specifically insured for that risk.
>> 
>> Another option is to go some way towards having each RP and OP come to some basic understanding of what is implied in terms of recourse, not by having them entering into a separate agreement (although preferable from a legal point of view, I would not recommend it) but by pre-defining recourse provisions as part of the metadata for the claims. One could think about defining a menu of options, ranging from 'no recourse whatsoever to OP',  'no recourse to OP except demonstrated gross negligence/wilful misconduct' and, at the other end of the spectrum, 'full recourse to OP' (not for the faint-hearted OP). OPs would state what their liability policy is for Verified Claims and it would be up to RPs to determine whether they can accept Verified claims with no or limited recourse provisions.  Ideally you would have more categories or categories more specifically tailored to specific eID frameworks - such as the eIDAS framework, but I suspect doing this for national AML regulatory frameworks is going to be very challenging.
>> 
>> A third alternative would be to have 'by default' liability provisions enshrined in the framework, but that would mean ensuring that whoever uses the framework (RPs and OPs) is legally bound by the provisions. You could envisage that the default liability regime would be the 'no recourse to OP except demonstrated gross negligence/wilful misconduct' with the option to deviate from that default option for specific situations, to be agreed between OPs and RPs. I am not familiar enough with the OpenID Connect implementation processes to assess whether this is a realistic approach (you would need to ensure that RPs are indeed bound by the rule).  At least this is something that one could consider.
> 
> To me this sounds like rising degrees of automated contracting between RP and OP.
> 
> In my experience liability is typically coupled with commercial aspects (pricing!). That in turn means there is settlement needed between the parties.
> 
> I believe liability and price will be negotiated among the parties or there is a regulation in place (like PSD2) that defines the legal basis and the price (PSD2 - free of charge).
> 
> I see this clearly out of scope of our technical specification.
> 
>> 
>> Any other idea?
> 
> We could add a section on liability and clearly state this is out of scope and subject to (a) agreements between the parties or (b) applicable regulation.
> 
> a) is how we do it in yes®
> b) is (in my opinion) eIDAS
> 
> best regards,
> Torsten.
> 
>> 
>> Stéphane
>> 
>> 
>> 
>> 
>> 
>> -----Message d'origine-----
>> De : Torsten Lodderstedt <torsten at lodderstedt.net> Envoyé : vendredi
>> 27 mars 2020 16:17 À : Stephane MOUY <sgmouy at stephanemouy.com> Cc :
>> OpenID eKYC Identity Assurance Working Group
>> <openid-specs-ekyc-ida at lists.openid.net>
>> Objet : Re: [OpenID-Specs-eKYC-IDA] Issue #1188: Embedded liability
>> implications in the framework? (openid/ekyc-ida)
>> 
>> Hi Stephane,
>> 
>> do you have a concrete proposal? What shall we change in the spec in order to resolve your concerns?
>> 
>> best regards,
>> Torsten.
>> 
>>>> On 27. Mar 2020, at 16:12, Stephane MOUY via Openid-specs-ekyc-ida <openid-specs-ekyc-ida at lists.openid.net> wrote:
>>> 
>>> Well, I remain unconvinced. I wish we could all agree this is a trust framework matter that is entirely separate from, and has no impact on, the OP/RP relationship, meaning it would not need to be dealt with here, but I do not think this is legally correct - and I am saying this knowing this may not be viewed as a 'positive' contribution.
>>> 
>>> Granted, there is a jurisdictional element in the discussion as the matter is most likely to be governed by the law of the OP (pursuant to art. 4.2 of EU Regulation 593/2008).  We are not attempting to regulate the substance of the liability implications - this is obviously beyond the scope of the project (no debate about this!) but it certainly does not mean that there is no liability issue for OPs. On the contrary, the default position should be : since OPs are attesting to the veracity/trustworthiness of certain information towards third parties who are explicitly relying on it, whatever liability implications result from this must be assessed under their own legal environment.  For me this is the only sensible position and simply assuming as a matter of principle there is no issue is, well, delusional. I suspect most lawyers will confirm that view - certainly most lawyers advising financial institutions (I was one of them for many years).
>>> 
>>> Whether liability can be mitigated or eliminated is therefore jurisdiction-specific and I will readily agree that no general guidance can be offered here - which incidentally adds another layer of complexity for the deployment of the framework.
>>> 
>>> I also doubt that OPs can avoid liability because RPs can somehow verify the information independently, as seems to be implied. Not so much from a theoretical point of view - this could indeed be a sufficient liability mitigant if it can be readily done in practice (but again, whether this fully eliminates liability will have to be assessed by OPs in accordance with their own laws) - but rather because I really doubt it is an available option for the vast majority of use cases. I am not even sure it works for eIDAS notified schemes - possibly yes but bear in mind that this is fact-specific, meaning that if the relevant relying party is not, for any reason, in a position to independently double-check the information, then I fear the most likely outcome is that the OP will be on the hook. For other Trust frameworks, in particular AML-regulations (national or international) that I suspect constitute the vast majority of use cases, I really do not see how this can work at all as there is no trust anchor to speak of. Indeed, for this to work, you would need a third party capable of assuming liability, such as the notifying member State under the eIDAS regulation (see art 11) , but there is no such entity for AML rules. It follows that if something goes wrong, recourse is likely available against the party that attested to the wrong data - the OP.
>>> 
>>> Lastly, I agree that RPs are responsible for ensuring that the verified claims they are requesting are tailored to their own situation (not that of the OP involved). To illustrate the point, if a RP asks for a Low LoA ID attribute when it should get a High LoA one instead in light of the risk profile of its own situation, that is clearly its own responsibility and it certainly should not blame the OP for that situation, but this is a different matter, distinct from the one discussed above.
>>> 
>>> Best
>>> 
>>> Stéphane
>>> 
>>> 
>>> -----Message d'origine-----
>>> De : Openid-specs-ekyc-ida
>>> <openid-specs-ekyc-ida-bounces at lists.openid.net> De la part de
>>> Anthony Nadalin via Openid-specs-ekyc-ida Envoyé : jeudi 26 mars 2020
>>> 18:56 À
>>> : OpenID eKYC Identity Assurance Working Group
>>> <openid-specs-ekyc-ida at lists.openid.net>
>>> Cc : Anthony Nadalin <tonynad at microsoft.com>; sgmouy
>>> <issues-reply at bitbucket.org> Objet : Re: [OpenID-Specs-eKYC-IDA]
>>> Issue
>>> #1188: Embedded liability implications in the framework?
>>> (openid/ekyc-ida)
>>> 
>>> Liability is a jurisdictional legal issue and should not be in in the framework per say, there may be things that one could use to base liability upon but that would be up to the jurisdiction.
>>> 
>>> -----Original Message-----
>>> From: Openid-specs-ekyc-ida
>>> <openid-specs-ekyc-ida-bounces at lists.openid.net> On Behalf Of Achim
>>> Schlosser via Openid-specs-ekyc-ida
>>> Sent: Thursday, March 26, 2020 10:13 AM
>>> To: OpenID eKYC Identity Assurance Working Group
>>> <openid-specs-ekyc-ida at lists.openid.net>
>>> Cc: Achim Schlosser <achim.schlosser at enid.eu>; sgmouy
>>> <issues-reply at bitbucket.org>
>>> Subject: [EXTERNAL] Re: [OpenID-Specs-eKYC-IDA] Issue #1188: Embedded
>>> liability implications in the framework? (openid/ekyc-ida)
>>> 
>>> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbit
>>> b
>>> ucket.org%2Fopenid%2Fekyc-ida%2Fissues%2F1188%2Fembedded-liability-im
>>> p
>>> lications-in-the&data=02%7C01%7Ctonynad%40microsoft.com%7C9596a6e
>>> 3
>>> 18554dda2a1308d7d1ada1ad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
>>> C
>>> 637208415985290184&sdata=CPpF6WHaAZEKncNKXt0IAwSin716ivtaIpDKeqza
>>> r
>>> 4c%3D&reserved=0
>>> 
>>>  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
>>> 
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
>>> s
>>> .openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ekyc-ida&data=02%
>>> 7
>>> C01%7Ctonynad%40microsoft.com%7C9596a6e318554dda2a1308d7d1ada1ad%7C72
>>> f
>>> 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637208415985300176&sdata=
>>> %
>>> 2BMDjJSvbupsYjKMLHvJVK67%2FrORhi2CYV44eAVbObes%3D&reserved=0
>>> 
>>> 
>>> --
>>> Openid-specs-ekyc-ida mailing list
>>> Openid-specs-ekyc-ida at lists.openid.net
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
>>> s
>>> .openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ekyc-ida&data=02%
>>> 7
>>> C01%7Ctonynad%40microsoft.com%7C9596a6e318554dda2a1308d7d1ada1ad%7C72
>>> f
>>> 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637208415985300176&sdata=
>>> %
>>> 2BMDjJSvbupsYjKMLHvJVK67%2FrORhi2CYV44eAVbObes%3D&reserved=0
>>> --
>>> Openid-specs-ekyc-ida mailing list
>>> Openid-specs-ekyc-ida at lists.openid.net
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
>>> s.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ekyc-ida&data=02
>>> %7C01%7Ctonynad%40microsoft.com%7C5e218d30f29e49c0194508d7d26f4e54%7C
>>> 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637209247813325172&sda
>>> ta=6zznMQ14rriRFeQ3tCdz6YZ22k4QWrqlHFA%2BCmFIMp4%3D&reserved=0
>>> --
>>> Openid-specs-ekyc-ida mailing list
>>> Openid-specs-ekyc-ida at lists.openid.net
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
>>> s.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ekyc-ida&data=02
>>> %7C01%7Ctonynad%40microsoft.com%7C5e218d30f29e49c0194508d7d26f4e54%7C
>>> 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637209247813325172&sda
>>> ta=6zznMQ14rriRFeQ3tCdz6YZ22k4QWrqlHFA%2BCmFIMp4%3D&reserved=0
>> 
> 
> --
> Openid-specs-ekyc-ida mailing list
> Openid-specs-ekyc-ida at lists.openid.net
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ekyc-ida&data=02%7C01%7Ctonynad%40microsoft.com%7C5e218d30f29e49c0194508d7d26f4e54%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637209247813325172&sdata=6zznMQ14rriRFeQ3tCdz6YZ22k4QWrqlHFA%2BCmFIMp4%3D&reserved=0
> --
> Openid-specs-ekyc-ida mailing list
> Openid-specs-ekyc-ida at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida


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