Privacy Considerations and Identifiers

Issue #124 resolved
Dave Tonge created an issue

As part of the work to split the draft, I've change the privacy considerations to the following. We've discussed the use of ephemeral identifiers in the FAPI WG, but I think that it is relevant to the core spec. Note, that this doesn't affect the actual CIBA flow at all - it just describes some alternative means of the RP obtaining a valid identifier for the end-user without requiring the user to share a static identifier such as a phone number. The text is currently in this branch:

This flow requires the Client to obtain an identifier for the end-user. When this identifier is a static global identifier, such as a phone number or email address, there are clear privacy implications. However this flow does not require the use of such identifiers and in deployments with higher privacy requirements, alternative identifiers could be used, such as:

  • ID Token containing a pairwise identifier

In situations where the Client has previously obtained an ID Token for the end-user, by means of a standard redirect flow, that ID Token can be passed as an id_token_hint. Despite it's name the ID Token may only contain a pairwise subject identifier claim and no claims that contain personally identifiable information.

  • Ephemeral identifier generated by OP - transferred from AD to CD

The OP could generate a single-use identifier which could be transferred from the Authentication Device to the Consumption Device at the start of the flow. For example, the user could authenticate at the AD and request an identifier for a CIBA flow. This could be displayed as a QR code, the user could scan this QR code at the CD. The RP would then decode the identifier and embed it in a login_hint_token which it would use to initiate the flow. The OP would then gain consent from the end-user for the access requested by the RP.

  • Ephemeral identifier generated by OP - transferred from CD to AD

The RP could request that the OP generate a transaction identifier via a custom backchannel endpoint (this could be an intent or payment id). This identifier would then be transferred from the Consumption Device to the Authentication Device and used as a hint in the authentication request, allowing the OP to correlate the CIBA flow with an end-user. For example the RP could request an intent id from the OP. It could then start a CIBA flow with the intent id embedded in a login_hint_token. At the same time it could encode the intent id as a QR code and display it to the user on the CD. The user would then authenticate on the AD and scan in the QR code. The OP would correlate the CIBA flow with the end-user and proceed to gain user consent for the access requested by the RP.

  • Discovery Service

For some ecosystems the RP may be able to send the user to a discovery service and receive back an encrypted login_hint_token which it can use in the authentication request. The OP would decrypt the token, identify the user and continue the CIBA flow.

Comments (8)

  1. Dave Tonge reporter

    We discussed this on the call and there was some support and no disagreement as to the inclusion of this type of text in the spec.

    There was some confusion around which method uses id_token_hint and which uses the login_hint_token - I'll update the text to reflect that. There was also discussion around the fact that id_token can be used multiple times - which should probably be reflected.

    WG members are going to review the text and comment.

  2. Dave Tonge reporter

    @tomcjones thanks for this point. I think your points are out of scope of this spec however. All I'm trying to illustrate is that a CIBA flow may not require the RP to know a static identifier for the user in the same way that standard redirect flows don't require the RP to know a static identifier.

    Depending on the end-user proposition, the RP may be required to know a static end-user identifier for the reasons that you mention. I think this is a separate point however. Furthermore as a user it may be beneficial from a privacy perspective if I can use one static identifier with the RP and a different static identifier with the OP.

  3. Dave Tonge reporter

    I've reworked the privacy considerations:

    Hopefully this is a bit clearer, but if the 3rd example (now called: Transaction identifier - transferred from the CD to the AD) isn't clear, I'm happy to remove it. Although it does seem a bit convoluted, the reality is that in more and more ecosystems there is a concept of an "intent id" so re-using it in CIBA wouldn't require any extra endpoints.

  4. Log in to comment