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

Need of a customer unique/immutable identity as part of ID Token

Issue #223 open
Anoop Saxena created an issue

Use case:

  1. Users may have more than one login at a bank or may be using spouse login along with their own login in Client product.

  2. During re-authentication when user is delegated to be authenticated at bank website. User may enter different valid login than what was used originally. This results in clients getting different set of accounts.

    1. Try to solve by comparing before and after new re-auth token may not be reliable as accounts can get closed or both users may be joint accounts.

  3. In absence of actual user context (an identifier of login user) it will be harder for clients to determine if user entered different set of login credentials.

  4. Current value of “sub” field is not reliable as it may change when user goes through re-auth flow.

Proposal:

  • Add a unique non-PII/non-PCI identifier as part of ID Token that unique/immutable within a provider/banks will help resolve this issue. Where clients can compare before and after identifier.

Comments (21)

  1. Tom Jones

    I don’t think that this request is limited to FAPI. I ran into the same problem when trying to create a self-issued token. It could, for example, hold a did or other ID. Would it be ok to copy this to the AB/C list?

    Should we call it a uid?

  2. Ralph Bragg

    The OBIE specifications includes the ablity for banks to put into sub

    • A static ID known to the bank, tpp and customer
    • An ephemeral ID known to the bank only
    • A static pair wise identifier that ties the PSU (customer) uniquely and forever to that Bank + TPP combination. i.e the identifier can’t be used accross TPPs.

    What isn’t included in the spec is a definition of what the sub type or the type of identifier is. We included some of these types of id in the CIBA / FAPI CIBA comments suggest these are aligned to those types?

  3. Tom Jones

    I think the issue is that we may need two fields with different names. Sub types may be interesting, but is different afaik.

    I get this problem on banks where more than one account is associated with one logon. Which happens a lot to me and some banks just aren’t able to cope with it at all. Others do it quite well.

    The specific issue i have is when the logon credential changes but the real person/persona does not. (that is not a banking case, i think the banks know how to do that. Other sites/methods do not.)

  4. Anoop Saxena reporter

    I see implementation of UK banks (CMA9) in OBIE copying OB consent id into “sub” field and this data is changing with every re-authentication or re-consent flow. I think somewhere in OB documentation mentions about this deviation of it is ok to copy consent id.

  5. Torsten Lodderstedt

    I understand the desire to identify the user but I don’t see an obligation (at least under PSD2) of the bank to provide the TPP with an immutable user id. The bank is obliged to authorise access of the TPP to account information or payment initiation.

    This would typically be implemented using OAuth, which intentionally does not reveal the user’s identity with the AS or RS to the client. The reasons OpenID Connect is used in FAPI were merely due to better security properties at the time FAPI started. With OAuth code + PKCE + JARM, there wouldn’t even be a sub.

    From a legal perspective, providing the TPP with a user id (== establishing an id federation) would put the liability for the correctness of this id onto the bank.

  6. Anoop Saxena reporter

    @Torsten Lodderstedt Yes I understand there is no obligation in PSD2 and it failed to address this use case. Prior to PSD2 when clients screen scrape data they used to have identifier (login id/user id) and due to delegated model (OAUTH or OpenID/FAPI) we lost this vital piece of data. As we are strengthening security model forgetting the use cases around customer identifier … “sub” field was suppose to address that need.

    Maybe it should be explained/influence to educate the need in PSD2 which promises the same level data access as screen scrape use to provide. With that principle we have a gap.

  7. Torsten Lodderstedt

    In my understanding PSD2 is supposed to provide account information and payment initiation services only and not to entirely replace screen scraping.

    Exposure of user/person data is still subject to discussions and is more a regulatory than a technical question.

    See for example this EBA answer on names and surnames: https://eba.europa.eu/single-rule-book-qa?p_p_id=questions_and_answers_WAR_questions_and_answersportlet&p_p_lifecycle=0&p_p_state=normal&p_p_mode=view&p_p_col_id=column-1&p_p_col_pos=1&p_p_col_count=2&_questions_and_answers_WAR_questions_and_answersportlet_jspPage=%2Fhtml%2Fquestions%2Fviewquestion.jsp&_questions_and_answers_WAR_questions_and_answersportlet_viewTab=1&_questions_and_answers_WAR_questions_and_answersportlet_questionId=2273222&_questions_and_answers_WAR_questions_and_answersportlet_statusSearch=1

  9. Nat Sakimura

    Use case:

    1. Users may have more than one login at a bank or may be using spouse login along with their own login in Client product.

    2. During re-authentication when user is delegated to be authenticated at bank website. User may enter different valid login than what was used originally. This results in clients getting different set of accounts.

      1. Try to solve by comparing before and after new re-auth token may not be reliable as accounts can get closed or both users may be joint accounts.

    3. In absence of actual user context (an identifier of login user) it will be harder for clients to determine if user entered different set of login credentials.

    4. Current value of “sub” field is not reliable as it may change when user goes through re-auth flow.

    Proposal:

    • Add a unique non-PII/non-PCI identifier as part of ID Token that unique/immutable within a provider/banks will help resolve this issue. Where clients can compare before and after identifier.
  10. Tom Jones

    I agree with both Torsten & Nat. There is no obligation, but the ux is better if the user context can be maintained. That is basically what cookies are for in any case. Perhaps a cookie solution is better than an open id solution?

    Here is another use case. I have a verifiable credential tied to a did. I want that to be one of the claims that i communicate to the RP. Question - is that within the scope of the oidc?

  11. Torsten Lodderstedt

    I personally don’t understand why it is considered a problem if the user decides to use different user accounts in the context of different authorization processes. Basically, it’s the decision of the user what accounts it wants to expose to the client or what account it uses for a certain payment initiation. Especially in case of a payment initiation, I could imagine it’s considered a feature from the user’s perspective to be able to use different user and bank accounts.

    This clearly completely changes if the client wants to use the financial institution as IDP and wants to rely on its login (ID federation). In this case, OpenID Connect has all the necessary means to set up and keep the user context. The ID Token has “iss” and “sub” and the client (RP in that case) can utilize the id_token_hint parameter to enforce a certain user account at the OP.

    @Nat Sakimura What is the difference between the identifier you are proposing and the sub Claim?

  12. Tom Jones

    The term “account” actually has different meanings in the first paragraph and the second paragraph. In the first it is the bank account with a TR or card number.

    In the second the account is a user name and authentication method.

    Which one do you think the id_token_hint applies to?

  14. Tom Jones

    Both of the accounts are user accounts.

    I will assume you mean the login account. That will contradict your assumption that the user can select which account to use. Unless we require pairwise sub and require the bank to associate the sub to a bank account. Which actually implies the opposite.

    Oidc is not well adapted to the realities of multiparty interactions.

  15. Torsten Lodderstedt

    The first part of my comment describes why I don’t think there is any problem if a user logs into the her bank with different user account in typical PSD2 scenarios … just because it doesn’t matter from the outside. The client wants the get authorization for a payment? It doesn’t matter what online banking user account the user logs in with and what actual banking account the money is transferred from. That’s a simple OAuth use case.

    The second part describes how a client can ensure a synchronized login state with the bank if the client uses the banking login for its own login (id federation) vis OIDC.

    That’s not in PSD2 scope but could be solved with OIDC. That’s the use case for id_token_hint. The client just uses an id token it received from the OP to indicate the expected user account with the OP.

    What’s wrong with it?

  16. Joseph Heenan

    Discussed on today’s call.

    There was a suggestion to provide some guidance to architects deploying FAPI to call out the need for certain things to replace screen scraping, e.g. that sub is persistent / that TPPs can explicitly request that the same user as before authenticates when redirected to bank / that PSU should not be required to reauthenticate with bank regularly.

  17. Dima Postnikov

    FYI In Australia, ID token will contain persistent identifier:

    “The identifier for an authenticated end-user (subject) MUST be passed in the sub claim of an ID Token and UserInfo response as defined by [OIDC].

    The Data Holder MUST generate the sub value as a Pairwise Pseudonymous Identifier (PPID) as described in section 8 of [OIDC]. Furthermore, the identifier SHOULD also be unique relative to the scenario in which the end-user has authenticated. For example, the identifier generated for the same person when they are using a business account SHOULD be different to the identifier that is generated when that same individual is authorising as an individual.

    It is RECOMMENDED that the sub value is generated as a version 4 Universally Unique Identifier (UUID) [RFC4122].”

    I believe this was added based on the learnings from the UK.. No one objected to this, so it’s more likely to stay.

    https://consumerdatastandardsaustralia.github.io/standards/#security-profile

    The rest of the spec is not 100% ready, e.g.:

    Re-authorization flow hasn’t been decided yet. CIBA is one of the options considered which would support id_token_hint….

  22. Log in to comment
Assignee
Type
enhancement
Priority
major
Status
open
Component
Implementation & Deployment Advice
Milestone
–
Votes
0
Watchers
9
Jira: the preferred issue tracker for Bitbucket. Join the team!