CIBA: End-user Identifiers
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.
Comments (12)
-
-
reporter This is a good point.
There are different scenarios for the use of these "hints" in CIBA:
-
Discovery Service provides login_hint_token This is more than a hint - a discovery service has provided an identifier that the OP can use
-
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 -
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.
-
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.
-
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": "user@example.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", }
-
-
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
-
reporter Ralph, Joseph and Freddi - what do you think? We need to get this closed off.
-
reporter - changed status to open
-
reporter 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.
-
reporter @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.
-
-
assigned issue to
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.
-
assigned issue to
-
reporter 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.
-
reporter @Joseph Heenan 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.
-
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
-
- changed status to closed
CIBA: Add a note referencing secevents subject identifiers
Text as suggested by Dave Tonge but tweaked a little.
closes
#174→ <<cset 3be60b825311>>
- Log in to comment
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.