Privacy Considerations and Identifiers

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: https://bitbucket.org/openid/mobile/branch/ciba-split

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)