Confidential client needs a strong identity for the user to verify real world entity
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
- 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)
-
-
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.
-
reporter By the way, I consider any site like a bill collector becoming a registered PISP to be an attacker.
-
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
-
reporter thanks for the info. All the more reason to call out the need for strong ID that the user can see.
-
We got onto discussing EV certs on
#135but 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.)
-
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)
-
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.
-
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
-
reporter - changed title to Confidential client needs a strong identity for the user to verify real world entity
-
- changed status to open
Any update for the implementer's draft?
-
Assigned to Ralph to come up with a concrete wording.
-
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)
-
-
assigned issue to
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.
-
assigned issue to
-
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)
-
-
assigned issue to
Dave to update based on suggesting wording from Joseph
-
assigned issue to
-
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.
-
-
assigned issue to
-
assigned issue to
-
-
We agreed to cover these issues in the privacy considerations: https://bitbucket.org/openid/fapi/pull-requests/187
-
- changed status to resolved
We now have privacy considerations that call out the risk that a user could be confused by who the RP is
-
reporter Based on the direction that Google is taking on web IDs, my thinking here is evolving.
I have tried to capture what i understand so far in the paper that i am working with in DIF & W3C. Any feedback would be good. For example, what are the privacy concerns that are now changing your positions?
https://tcwiki.azurewebsites.net/index.php?title=WebID_Comparison
-
- changed component to Part 2: Advanced
-
- changed component to FAPI 1 – Part 2: Advanced
-
- changed component to FAPI 1: Advanced
- Log in to comment
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.