1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. fapi
  4. Issues

FAPI 2.0: x-fapi-* headers

Issue #282 open
Torsten Lodderstedt created an issue

The spec currently states the client can send x-fapi headers, but does not give a rationale nor describes what is the AS supposed to do with those headers. Please plarify.

Comments (23)

  1. Stuart Low

    At least for x-fapi-interaction-id this is quite useful for tracing of flows through multiple layers on both OP and RP sides. It’s also potentially useful for reporting an error message that can be looked up in logs but is consistent across all participants.

  7. Joseph Heenan

    I think we should drop the ip address and auth date headers.

    ‌

    I believe at least UK & CDR are using these headers to mean ‘customer present’. If we do drop them we should probably address that somehow.

  9. Dima Postnikov

    In CDR, IP address is used as an ‘customer present’ indicator. Mandatory, if customer is present.

    Auth date is a mandatory ‘last auth date’.

    Not sure what the benefit of these or the quality / consistency of the the values supplied.

  10. Dave Tonge

    So if starting from scratch with these specs, I would say that “customer presence” data is metadata that the AS may need to be aware of, but that should be irrelevant to the RS.

    When such metadata is needed for an initial authorization decision, then it should be sent in RAR data.

    When such metadata is needed to justify ongoing access, then it would seem to make sense to me to define an extension to the refresh token grant. For example under the PSD2 legal framework a Client could have the permission to get an access token (that lasts for 10 minutes) 4 times every 24 hours. If the Client wanted to access more than that, the condition would be that the customer is present. The Client could send the customer IP address and auth time to the token endpoint when requesting a new access token. This would keep logic simple:

    • the RS could just trust the access token
    • the AS could have the logic when issuing access tokens in the refresh token grant to check how many times tokens have been issued in the last 24 hours

    Sending “customer presence” metadata to the RS doesn’t seem right as it confuses authorization and resource access.

  11. Dave Tonge

    we discussed on the call today. There was a case made that it is important for the RS to have “customer present” information.

    A further point that I believe is relevant to this - if this information is important and may need to be signed in the future, then any signing mechanism will need to support signing of HTTP headers if the information is sent in http headers.

  12. Dave Tonge

    we had more discussion on the call and the following was discussed:

    • continuous authorization is important to support - the RS needs to be able to have additional data from which authorization decisions may be made
    • the data may not be able to be relied on from an accuracy perspective, but an RS may need to keep the data for audit purposes, and there may be legal requirements on how they deal with requests
    • given that the data may be needed for audit purposes, it should probably be signed in FAPI2 advanced
    • should the headers start with x-
    • should we define an extensible way for this information to be passed from the client to the RS or just let ecosystems come up with their own headers

    ‌

  13. Daniel Fett

    I propose that we drop these headers from the spec.

    • From the use cases listed above, the headers are not really a security feature.
    • Ecosystems may define their own headers anyway. I do not see much value in proposing a header name without defining semantics and how to act on the information transported. Unlike RAR, this is not a feature where we expect a benefit from widespread adoption.
    • An option would be to suggest to ecosystems to use a prefix like “x-fapi-” or “fapi-” for such headers, maybe giving “(x-)fapi-interaction-id” and “(x-)fapi-client-ip-address” as examples. I don’t see, however, what the benefit of creating such a namespace would be.

    ‌

  15. Daniel Fett

    Removed the x-fapi- headers in master pending further discussion after the 1st Implementer’s Draft

  18. Dave Tonge

    We discussed this on the call today.

    There was discusision that if we do keep any of these headers, we should keep the x- prefix as it doesn’t make sense to cause breaking changes over 2 characters.

    We discussed that the x-fapi-interaction-id could be useful for auditing purposes and it could make sense to add it back into the spec.

    We had some discussion around the ip address and auth time. There was some discussion of making use of this header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For to pass through the end-user IP address.

    We discussed that it would be good to resolve this issue on next weeks call.

  20. Dave Tonge

    We had a long discussion about this on the call yesterday.

    We agreed that it would be better to move these headers to implementation advice, rather than have in the core spec.

    We discussed that IP Address / Last auth time are problematic due to the fact that IP address can be PII and that the main usage of those headers has been to indicate whether a customer is present - but that is not clear at all. We discussed perhaps specifying a different header to indicate whether a customer is present. However we decided that such a header would only be a signal and wouldn’t be able to be trusted. Putting such a header in a security profile may

    We agreed to leave this ticket open and start the FAPI 2 Implementation Advice document. There is still some disagreement about whether interaction-id belongs in the security profile, or in a different spec.

    We noted that ecosystems are free to use the exiting x-fapi headers and still be fully conformant with FAPI 2. Indeed the UK and Australia already add extra requirements around these headers (and define extra headers).

  24. Log in to comment
Assignee
Type
bug
Priority
major
Status
open
Component
Implementation & Deployment Advice
Milestone
2nd Implementers Draft
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!