CIBA: End-user Identifiers

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2018-09-12

CIBA uses the concept of a login_hint_token.

There is a mobile specific definition of this here:
https://openid.net/specs/openid-connect-modrna-authentication-1_0.html#rfc.section.6

But we need a more generic definition - that can work in a banking context.

As Brian mentioned there is existing work in this area in the SECEVENTS working group at IETF:
https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-00

Perhaps we could utilise the above draft?

I'm opening this issue so that discussion can start while the core CIBA spec is being worked on.

---

Bitbucket status: closed

Bitbucket origin: issue 174

[bitbucket-import-issues]

Originally submitted by Torsten Lodderstedt (Torsten Lodderstedt) on 2018-09-13

what is the expectation regarding use of the different hints? Is the client supposed to know the user id or is it really just a hint (which may be useless)? I'm asking because in the latter case, the login_hint with the adapted explanation (https://bitbucket.org/openid/connect/issues/1046/core-3121-id_token_hint) could server the role id_token_hint was supposed to serve.

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2018-09-20

This is a good point.

There are different scenarios for the use of these "hints" in CIBA:

1. Discovery Service provides login_hint_token
   This is more than a hint - a discovery service has provided an identifier that the OP can use

2. Previously issued id token used as id_token_hint
   We've discussed this and because of the difficulty of verifying such a token, in reality the main value is extracting the sub claim from such a token. If the OP is issuing pairwise identifiers, then there is no benefit in providing the whole id_token vs just the identifier

3. OP issued ephemeral user identifier
   This would be a one-time use identifier that the OP would generate and that the user would pass to the RP to start a CIBA flow (e.g. a QR code is generated in a banking app and scanned at a POS terminal.

4. OP issued transaction identifier
   In a PSD2 context, this would be the "intent id" for a payment / account information request. The RP would request this id from the OP and would then display it to the user (and at the same time start a CIBA flow) The user would scan the identifier into their banking app. The OP would then connect the user with the intent id.

5. User entered identifier
   Such as an email, phone number, or username.

Given that an OP may decide to support multiple types of identifier, it seems beneficial to have a structured format for them.

I agree with you that id_token_hint isn't that valuable, but I still think for CIBA we need a structured login_hint. The nature of CIBA is that its always more than a hint - the flow can't continue unless the OP can find a user with the identifier given by the RP.

I like the idea of using the subject identifiers draft. For example we can have:

{
"subject_type": "email",
"email": "userexample.com",
}

{
"subject_type": "iss_sub",
"iss": "http://issuer.example.com/",
"sub": "145234573",
}

We could define for CIBA

{
"subject_type": "iss_ephemeral_id",
"iss": "http://issuer.example.com/",
"ephemeral_id": "145234573",
}

{
"subject_type": "iss_transaction_id",
"iss": "http://issuer.example.com/",
"transaction_id": "145234573",
}

[bitbucket-import-issues]

Originally submitted by Torsten Lodderstedt (Torsten Lodderstedt) on 2018-09-24

re 2) you assume the OP determines the PPID's context based on the client_id of the request? Otherwise, the id token's aud claim would be needed.
re 3) how does the OP issue this identifier? Does it use an authenticated context with the user?
re 4) do you really assume the intend id may serve as a user identifier? I assume the user is unknown when the intend resource is created.
re 5) fits the login_hint text

Subject Identifiers Draft: https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-00 - it looks promising

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2019-02-27

Ralph, Joseph and Freddi - what do you think? We need to get this closed off.

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2019-02-27

Although it doesn't change the core flow at all. I think ti would be really helpful to have a defined way of specifying hints.

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2019-02-27

tlodderstedt_yes_com apologies for the delay.

re 2) you assume the OP determines the PPID's context based on the client_id of the request? Otherwise, the id token's aud claim would be needed.

Yes - the client id would have to be communicated in some way. Maybe there is a need for something like this:
{subject_type: "iss_ppid", iss: "https://example.issuer.com", aud: "client_id}
That way client authentication is distinct from the hint (although the OP will still need to verify that the authenticated client is allowed to use that hint)

re 3) how does the OP issue this identifier? Does it use an authenticated context with the user?
Yes it would use an authenticated context with the user. For example the user would authenticate with an app on their smart phone and press a button to generate such an identifier (which may be displayed as a QR code for a consumption device to read).

re 4) do you really assume the intend id may serve as a user identifier? I assume the user is unknown when the intend resource is created. re 5) fits the login_hint text
So the intent id is lazily bound to a user. So when it is first created the user is unknown. But eventually it will be linked. The use of an intent id requires the AS to implement logic outside of the spec.

[bitbucket-import-issues]

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

CIBA uses the concept of a login_hint_token.

There is a mobile specific definition of this here:
https://openid.net/specs/openid-connect-modrna-authentication-1_0.html#rfc.section.6

But we need a more generic definition - that can work in a banking context.

As Brian mentioned there is existing work in this area in the SECEVENTS working group at IETF:
https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-00

Perhaps we could utilise the above draft?

I'm opening this issue so that discussion can start while the core CIBA spec is being worked on.

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2019-06-05

Given the lack of traction on this. My suggestion is that we don’t make any specific recommendations around this. I think a note suggesting that implementers consider the “subject identifiers” draft could be useful though.

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2019-06-19

{josephheenan} maybe some text like this:

NOTE: While the login_hint and login_hint_token's formats are not
defined by [CIBA] or this profile, implementers should consider
https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-03
 for a standards based method of communicating user identifiers. 

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2019-06-21

Thanks Dave, I have opened a pull request adding your suggested wording here:

‌

https://bitbucket.org/openid/fapi/pull-requests/124/ciba-add-a-note-referencing-secevents/diff