CIBA: x-fapi-device-id header

[Dave Tonge]

For CIBA flows it doesn't always make sense for the client to send customer ip address or last logged in headers.

However it may be beneficial to send an identifier for the "consumption device", I've got this wording in the current draft of the FAPI CIBA profile:

In situations where the user does not control the consumption device, 
the client
 - shall not send x-fapi-customer-ip-address or x-fapi-customer-last-logged-time headers;
 - should send a x-fapi-device-id header which contains an identifier of the consumption device used by the customer.

NOTE: It may be useful for an FI’s fraud systems to know the device that is 
the source of payment initiation requests, hence the recommendation for 
the x-fapi-device-id header.

I'd welcome feedback on this.

[Sascha Preibisch]

In our CA's mobile SDK that we ship with our APIM solution we also have a device-id. It is always included whenever the client sends a request. This id is included when the client requests a token and also when the token is used on a protected API.

To be precise, the client first goes through a registration process which results in the server issuing that id. As of then it is always used by the client. This allows the server to be in control of the type of ID and prevent duplicates. It has been very useful so far.

[Nat Sakimura]

Agreed. It should be useful.

[Axel Nennker]

Do you recommend CIBA to be changed?

[Dave Tonge]

I think that would be a good idea. Although the name of the header should probably be simply device-id

[Dave Tonge]

we discussed that a device id probably wouldn't be useful, however a device type and geolocation could be useful.

[Axel Nennker]

Could you please clarify who would send or not send which information to whom for what purpose. Experts in FAPI probably know this from the issue description, while I don't.

Is this talking about the AZ sending fraud detection info to the authentication device which is then consumed by an authenticator app that changes the UI depending on the info?

Or is this talking about information send from the authentication device to the AZ? Or is this talking about info send from the AD to the AZ and the consumption device.

[Dave Tonge]

@ignisvulpis sorry for the delay in getting back to you.

This is about the client including metadata about the consumption device when posting the CIBA Authentication Request to the AS. For example device type could be: Petrol Pump | POS Terminal | Transport Ticket Machine, etc.

In a payments flow, the main use-case for this data would be to give the AS information that could help its fraud decision engine.

The metadata could be passed through to the authentication device to give the user more context on the access they are approving, but that is not it's intended purpose.

@ve7jtb and @Nat what should we do about this ticket - given that we don't have a suitable source of device types?

[Axel Nennker]

I would handle data that is shown to the user different to data that is used by the OP for fraud detection.

Arbitrary text shown to the user makes it easier to phish the user or to show inappropriate content or text that does not fit the screen space on the user device. Difficult topic.

Sending fraud prevention data to the OP and from that the OP chooses appropriate text to the user might be safer.

Or each Petrol Pump could be its own Client registered to the OP. That would provide the AZ with a client name at registration time.

[Dave Tonge]

I agree, that the data should be handled separately. I've adjusted the FAPI CIBA profile to say:

1. should send metadata about the consumption device, for example geolocation and device type.

NOTE: It may be useful for an FI’s fraud systems to know the location and type of the consumption device. The format and schema for such metadata is outside the scope of this profile.

[Dave Tonge]

This issue has already been addressed. There is a similar open issue though: https://bitbucket.org/openid/fapi/issues/146/ciba-fraud-indicator-standards-and-signed