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

CIBA: End-user Identifiers

Issue #174 closed
Dave Tonge created an issue

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)

  2. Dave Tonge reporter

    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": "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", }

  3. Torsten Lodderstedt

    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

  6. Dave Tonge 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.

  7. Dave Tonge 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.

  8. Nat Sakimura

    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.

  9. Dave Tonge 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.

  10. Dave Tonge 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.
  13. Log in to comment
Assignee
Type
proposal
Priority
major
Status
closed
Component
CIBA
Milestone
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!