1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. fapi
  4. Issues

Confidential client needs a strong identity for the user to verify real world entity

Issue #135 resolved
Tom Jones created an issue

i tried to create a pull for this, but the bitbucket tools are different from the ones i use for code and it doesn't seem to have worked.

here is what i proposed to add to 5.2.4

  1. shall provide a strong identity to the user, for example with EV certs, that will enable the user to determine the real-world identity of the entity hosting the client;

It is really hard for me to understand how a openid connect public client would be sufficiently secure to allow payment initiation.

Comments (25)

  1. Ralph Bragg

    Tom,

    That is essentially what Open Banking does, all clients registered at OPs are identified either directly or indirectly by the OB Issued Certificates whose identities are highly assured and can be referenced by the OB directory. The OB profile also explicitly allows OPs to not support public clients.

  2. Tom Jones reporter

    Those are both positive statements that i endorse. I should note that the FCA web page has been changed yesterday after my earlier email. https://www.fca.org.uk/consumers/account-information-and-payment-initiation-services

    But it still seems to say that it is the consumer's responsibility for checking the validity of a participant on the FCA/OB(?) web site. https://register.fca.org.uk/shpo_searchresultspage?preDefined=AIPISP&TOKEN=3wq1nht7eg7tr That seems wrong to me. The user should not be checking to see if the site is valid. It is very poor UX for the consumer to be blocked in making a web transaction to go to a site that they assuredly to NOT know the URL for before proceeding. My proposal would not accept that sort of UX.

    As far as an OP not supporting the public client, that just means an attacker could chose one that did allow public clients. Also not good security policy from the user's perspective.

  3. Tom Jones reporter

    By the way, I consider any site like a bill collector becoming a registered PISP to be an attacker.

  4. Ralph Bragg

    That's correct, it's one of the areas where Open Banking tries to enhance consumer protections. OB secured APIs can only be accessed by TPPs that are appropriately accredited by national competent authorities which will be checked once a day (or more) for each participant by OB, if a participant loses authorisation they're immediately revoked. There's lots of problems with the letter of the law of PSD2, particularly with regards to identification and authorization attestation of participants. The roles and liabilities of NCAs, QTSPs and participants themselves that are all partially responsible for the management of the eIDAS certificates that are supposed to be the only source of identity and authorisation is ill defined. The certs will carry insufficient information regarding authorization, most notably passporting information and are issued with with no ongoing liability or assurance that the information imbedded in the certificate remains correct and accurate.

    In a non OB environment, the consumer, if they choose to give away access to data and payment permissions, has to bare some responsibility.

    Hopefully it'll improve over the next few years but probably not until bad actors have caused sufficient trouble that regulators fix the current systemic issues

  5. Tom Jones reporter

    thanks for the info. All the more reason to call out the need for strong ID that the user can see.

  6. Joseph Heenan

    We got onto discussing EV certs on #135 but it's probably more relevant to reply here - Tom said:

    wow, what do you know about ev certs that i do not? https://en.wikipedia.org/wiki/Extended_Validation_Certificate afaik these provide good binding from the web site to a physical business of know provenance. Please tell me why you think that is not the case?

    I would disagree on the physical and provenance attributes, but otherwise agree. You have a direct link between a website the user is viewing and a legal entity of a given name.

    There are two angles to why EV doesn't help much with trust imho:

    1) Because life is complicated. If I bank with bank of scotland, I go to https://www.bankofscotland.co.uk to do my online banking; you'll look at the bottom of that page you'll see they have the legal name "Bank of Scotland plc is registered in Scotland No.SC327000.Registered Office: The Mound, Edinburgh EH1 1YZ. Authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority under registration no. 169628.". If you look at the EV certificate there, the browser is showing "Lloyds Banking Group PLC". The EV certificate is very clearly not for the entity I'm expecting. How many users do you think go and look up and check that bank of scotland is actually owned by Lloyds banking group, and how many blindly put in their details without even looking at the address bar?

    2) Because EV doesn't do anything to validate beyond checking the company name is correct and appears to be linked to the person applying. With places like https://certsimple.com/about doing EV in under 3 hours for 176 GBP, the checks they are doing are limited. As I understand it, there's no guarantee (or requirement) that they reject a company named "Amazon Payment Services Ltd" registered in China, if I have managed to legitimately get that company name registered in China. Yet a name like "Amazon Payment Services Ltd" showing in a browser as EV likely wins me a lot of trust with the user.

    There's no requirement in EV to check that a company isn't trying to impersonate another company or use someone else's trademark/brand name, nor is there any such requirement in most national company registers, and an EV certificate can be granted to a company that was literally registered today.

    The EV checks are not dissimilar to the checks Apple does when you try and register a company developer account, and in fact in some ways I'd argue a published app on Apple's AppStore under a companies name is pretty much equivalent to (or better than) an EV cert in terms of trust, as Apple will fairly quickly remove anything fraudulent and will ask some pretty hard questions if you try to publish an app that uses a well known trademark in it's name. (Google Play Store has a much lower standard I believe.)

  7. Tom Jones reporter

    I think you misunderstood. I mean ev to be a floor not a ceiling.

    I propose ev as a minimum or example. The main point for fapi is that some duty of care is required to present a validated real world identity of the client to the user. The FCA does also try to do that. Their problem is that they seem to be completely tone deaf as to what a user may actually want to know. Your example above clearly demonstrates that.

    thx ..Tom (mobile)

  8. Joseph Heenan

    I definitely agree with your point that there's some duty of care.

    I am not convinced that it makes sense for the client to prove it's identity to the user rather than, as is done in the UK OpenBanking model, for the bank to assert the identity of the client (as the bank knows the client's identity from the OpenBanking directory with a good level of checks having been done prior to registration onto that directory).

    At least within the OB model, I don't see the need to impose further requirements onto the client.

  9. Tom Jones reporter

    If the OB model does express the real world identity of the Client, then it would meet the requirement as i intended it.

    Peace ..tom

  13. Joseph Heenan

    Discussed on today's call; the thoughts seemed to be:

    1) We should add a spec clause along the lines of "the AS should ensure that clients have a strongly assured identity and show that identity to the user"

    2) The proposed implementation guide should cover some ways that a client identities can be assured (federation etc)

  14. Nat Sakimura

    Sounds like a trust framework policy issue and not protocol.

    We should see if we need to create a separate document on these trust issues.

  15. Joseph Heenan

    I’d suggest splitting my suggestion into two new clauses:

    the AS shall ensure it is confident of the identity of the client

    the AS shall show the user the identity of the third party they are granting access to

    (wording could no doubt be improved)

  17. Daniel Fett

    The proposal by Joseph makes sense.

    FWIW, there is not much value in using EV certificates, so we should not propose this as an option.

  26. Log in to comment
Assignee
Type
enhancement
Priority
major
Status
resolved
Component
FAPI 1: Advanced
Milestone
–
Votes
0
Watchers
1
Jira Software: the preferred issue tracker for Bitbucket. Join the team!