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

[bitbucket-import-issues]

Originally submitted by Anoop Saxena (Anoop Saxena) on 2019-04-30

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.

---

Bitbucket status: open

Bitbucket origin: issue 223

[bitbucket-import-issues]

Originally submitted by tomcjones (Tom Jones) on 2019-04-30

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?

[bitbucket-import-issues]

Originally submitted by Ralph Bragg (Ralph Bragg) on 2019-04-30

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?

[bitbucket-import-issues]

Originally submitted by tomcjones (Tom Jones) on 2019-04-30

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.)

[bitbucket-import-issues]

Originally submitted by Anoop Saxena (Anoop Saxena) on 2019-04-30

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.

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2019-05-30

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.

[bitbucket-import-issues]

Originally submitted by Anoop Saxena (Anoop Saxena) on 2019-06-03

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.

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2019-06-03

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

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2019-06-05

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.

[bitbucket-import-issues]

Originally submitted by tomcjones (Tom Jones) on 2019-06-05

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?

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2019-06-10

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?

[bitbucket-import-issues]

Originally submitted by tomcjones (Tom Jones) on 2019-06-10

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?