standard requires customer's cookies for logging in to data recipient to be provided to data holder

[jogu]

Description

The current draft says this about x-cds-User-Agent:

The customer's original standard http headers Base64 encoded, including the original User Agent header

I presume this isn't what's intended, as it would require the data recipient to send the 'Cookie' header that the customer used to access the data recipient. Access to that cookie header would likely let the data holder impersonate the customer and access the data recipient's service, exposing various PII included that received from other data holders, which is not something the data holder should have the ability to do.

Area Affected

https://consumerdatastandardsaustralia.github.io/standards/#http-headers

Change Proposed

Change to simply 'The customer's original User Agent header'. (I don't see any clear reason why base64 encoding would be required or helpful.)

[jogu]

Based on:

#13 (comment)

It seems the intention was actually to include all the users headers.

It seems that two changes are necessary:

1. If all the headers are included, 'x-cds-user-agent' is a really bad name that implies it only contains the user-agent and it should be renamed to more clearly indicate it.

2. There must be a whitelist of headers that it is safe to share with the data holder. It is clearly a massive privacy violation if the contents of the Cookie header are passed along, and whilst I appreciate that some data is necessary for fraud detection a Cookie header that would allow the data holder to access the data recipient impersonating the customer is clearly something that should not be sent.

[CDR-API-Stream]

As referenced, the intent was to include all user headers and was to support risk scoring for fraud detection.

The two additional comments are reasonable and we will consider this issue for inclusion in the current maintenance iteration.

The current text is explicit that only standard http headers are to be included which is a white list as the list of standard headers is well known. Rather explicitly state this list a clarification that security and authentication headers for the original service may be excluded by the data recipient may be preferred. This leaves the inclusion of these headers at the discretion of the data recipient.

[perlboy]

What benefit is intended to be derived from shipping headers of the data recipients preference? I understand the reasoning for sending browser user-agent details as this is useful for WAF signature analysis (particularly correlation across platforms) but essentially all other headers are mostly only relevant for the interaction between an end users browser and the data recipients service.

Specifically on "well known standard headers" this is open to high degrees of interpretation. For instance the Cookie header has been a standard since 1997 (RFC2109). Does this make it well known?

Outside of a browsers user agent the standards should either explicitly call out what headers they are expecting to be shipped or not require any additional ones at all. From my perspective I don't see what other headers would be useful.

[CDR-API-Stream]

Based on the provided feedback the language defining the headers to be included will be amended to indicate that all client headers should be included except:

• Headers containing security information
• Custom or proprietary headers used to facilitate the client application

[NationalAustraliaBank]

NAB doesn't support the general definition currently provided for what headers should be included. In order for NAB to provide effective fraud monitoring, the following headers are required at a minimum:

• CPU unique identifier
• Vendor ID - associated with device
• Device screen colour depth (bits)
• Device screen width in Y direction in rasters
• Language HTTP header
• User Agent HTTP header, including BrowserID and Browser Type
• IP address
• Device Type - eg. Samsung, Apple
• Longitude of the location of the IP address, range is -180 to +180
• Latitude of the location of the IP address, range is -90 to +90
• 3 digit ISO country code representing the location of the IP address
• City representing the location of the IP address
• Content (media) types
• Operating system on which browser is running
• Operating system language

[jogu]

@NationalAustraliaBank That's not a list of HTTP headers, and some (geo location data, device type, etc) is information NAB should be determining from other info already supplied (IP address, user agent, etc).

Other data (e.g. screen size) NAB can collect itself at the Authorization Endpoint.

[perlboy]

I'll add onto @jogu comments here and highlight that the CPU Unique Identifier is also a de-identifying attribute which, if not opt-in and at the choice of the end user, may be a violation of the Australian Privacy Principles Chapter 2.