Meaning of x-cds-subject header sent in banking API calls about standards-maintenance HOT 14 CLOSED

For clarity @NationalAustraliaBank's feedback requested the following headers in March 2019:

x-fapi-customer-id
x-fapi-customer-last-logged-time (currently present in CDR Standards)
x-fapi-customer-ip-address (currently present in CDR Standards)
The original user agent of the customer device (part of decision proposal #10 but not currently reflected in the CDR Standard documentation.

And then repeated this request and added the user agent in June 2019.

What's of note is that the requested headers of x-fapi-customer-id and x-fapi-customer-last-logged-time were only present in very early working drafts (WD01/WD02) but are not present in the FAPI Part 1 implementers draft. x-fapi-customer-id was dropped entirely, and x-fapi-customer-last-logged-time appears to have been renamed.

In summary:

1. The introduction of x-cds-subject is a varied regression of a header that was removed very early in the FAPI standardisation process
2. x-fapi-customer-last-logged-time appears to be a rename of the x-fapi-auth-date header

As @jogu has highlighted, the protections afforded by replaying sub appear to be dubious as it is data that is known to the holder and can be determined by the recipient using a valid introspection request using the same token through which the header would be presented.

It seems appropriate that x-cds-subject be dropped and x-fapi-customer-last-logged-time be aligned with the upstream standard.

EDIT: The conversation within FAPI WG that led to removal of x-fapi-customer-id circa February 2017 can be found here.

from standards-maintenance.

Yes

from standards-maintenance.

As I understand it, this clause requires the OpenID relying party to send to the resource server the sub value that they obtained from the authorization server.

What's the goal of this? I don't think any of the underlying standards require this, nor do any of the other ecosystems I'm aware of.

from standards-maintenance.

I think the header value can be used to uniquely identify a particular consent and relying party combination, since we send a UUID as the sub claim in the ID token.

from standards-maintenance.

It can, but that's not standard and means that information is being passed in two places as the relying party and the particular consent must also already be available from the access token (as x-cds-subject isn't supplied in unattended calls so you can't rely on it being available). I don't see the benefit in passing 'sub' in a second place and it would seem to be deviating from the underlying standards for no gain but a lot of potential for confusion and fragile/tightly coupled implementations.

from standards-maintenance.

The condition for the necessity of the header also appears contradictory.

Mandatory for authenticated calls. Not required for unattended or unauthenticated calls.

Can you please address the expectation for unattended authenticated calls in the overall clarification?

from standards-maintenance.

I'd strongly recommend removing it rather than clarifying. It's a significant deviation from the underlying specs, and has the potential to introduce new flaws and hence Australia would not be benefiting from the significant amount of formal security analysis that has already been done on OAuth2, OpenID Connect and FAPI specifications.

This is particularly as there doesn't seem to be any documented reason for diverging from the standards and introducing extra work for data recipients to do - the clear model in OAuth2 is that the access token is the method to communicate from the OAuth client to the resource server, and that is how other ecosystems do it. There is no reason I can see to add this extra element.

from standards-maintenance.

The purpose of this header, along with the Base64 encoded headers for the original request, are to support existing behavioural fraud monitoring implementations of the banks. These headers were specifically requested in feedback to the May draft of the standards and were agreed for inclusion. The inclusion of additional headers for risk scoring was also recommended by the independent security review.

Please refer to issues ConsumerDataStandardsAustralia/standards#70
and ConsumerDataStandardsAustralia/standards#78 for more details.

At this stage a change to the inclusion of these headers will not be considered.

from standards-maintenance.

Your response seems to have crossed over into the base64 thing; that's covered in #28 and I've expanded on my response there based on the extra info in the link you provided; thanks!

For x-cds-subject I think regardless it's clear that clarifications are needed to the text of the standard about this header; it does not appear to have anything to do with fraud monitoring based on the 'yes' response above ( #13 (comment) ). I can't find the actual text that refers to x-cds-subject in either of the links you pasted; can you point me at the exact comment or exact document page to look at please?

from standards-maintenance.

In the decision document in ConsumerDataStandardsAustralia/standards#70 - document link is here - refer to matter A14.

from standards-maintenance.

Thanks, that helps massively! So I believe this is the relevant text:

A14: HTTP Header Changes

Feedback:
The submission from NAB recommended changes to the headers required for authenticated end points to facilitate risk based decisioning and fraud data correlation that will be used to protect the interests of the customer.
This feedback also requested that the optionality tables for headers be made more consistent in the standards documentation.

Decision:
Request headers covering the user agent of the originating device, customer identifier and last authentication date will be included in the standards. The first of these headers will be mandatory for attended calls and the second and third will be mandatory for all calls.

I cannot see how the current interpretation of the current standard (i.e. "x-cds-subject header is the same as that of the "sub" claim of the ID-Token [returned from the data holder]" as clarified above) contributes to fraud prevention. It is the data recipient playing back data to the data holder that was provided by the data holder in the same session and that the data holder could lookup itself from the provided access token. It just introduces more work for the data recipient and introduces the potential that the data recipient plays back incorrect information.

It sounds like the original intent was that the identifier the data recipient holds for the user (e.g. perhaps the username at the data recipient, or a hash of the username) is sent to the data holder (though I would imagine in some cases that data recipient wouldn't hold any such data as they may intend to only use the data from the data holder for the duration of the current session, which may be authenticated at the data holder but unauthenticated at the data recipient).

I believe this definitely needs further clarification.

from standards-maintenance.

This has been a useful discussion. As this is a request for clarification and not a change request the clarification is: Yes, the x-cds-subject is the same as the "sub" claim in the ID Token.

If there is a desire for this header to be removed this should be raised as a change request with rationale. It will remain in the standard until that time as the inclusion was previously requested by the community and included after consultation.

from standards-maintenance.

Thanks, I opened a change request at #33 - there remain significant issues with this header that do require solving one way or another.

from standards-maintenance.

Thanks @jogu

from standards-maintenance.