Comments (14)
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:
- The introduction of
x-cds-subject
is a varied regression of a header that was removed very early in the FAPI standardisation process x-fapi-customer-last-logged-time
appears to be a rename of thex-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.
Related Issues (20)
- Additional field to support Step Tariff calculations HOT 18
- AuthorisationMetricsV2 abandonmentsByStage property descriptions and CDS Guide HOT 14
- EnergyPlanTariffPeriod - Change to daily supply charge HOT 13
- Addition of a DH-side endpoint for querying the status of a consent establishment flow HOT 13
- Maintenance Iteration 18 Holistic Feedback HOT 14
- Commercial Credit Card Structure under Get Account Details call
- Updates to 'Revoking consent' Standards HOT 4
- Concurrent consent support and cdr_arrangement_id HOT 4
- Collection Consents - Authorisation Amendment HOT 8
- Potential error in Telco specification HOT 2
- Include "Provider number" in GetDataHolderBrands Response HOT 1
- Remove BankingTransactionDetail and incorporate extendedData into BankingTransaction HOT 19
- Review Register API descriptions HOT 3
- Maintenance Iteration 19 Holistic Feedback HOT 3
- Retirement date for Get Generic Plan Detail v2 and Get Energy Account Detail v3 HOT 2
- Update CDS documentation to clarify expected rate value 'sign' (+/-) for each RateType HOT 6
- Update guidance for Banking account rate detail HOT 2
- Update TLS cipher suite requirements to address DHEat Attacks and Raccoon Attack vulnerabilities HOT 3
- AmountString field type impractical for energy tariffs HOT 12
- Set a character limit for resource identifiers
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from standards-maintenance.