Part 1: issues with x-fapi-customer-last-logged-time header

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2017-03-22

Reviewing Part 1, I found the following a little inconsistent in the description of the x-fapi-customer-last-logged-time header:

1. 'time' is used in the header to describe a time+date, whereas the HTTP/1.1 spec uses 'date' for the same purpose - I think we should be consistent with HTTP1/1.

2. I suggest changing 'logged' to 'login' to better reflect what I believe is the purpose of the header. ("logged" could also be interpreted as being related to system logging rather than user login.)

3. The reference to the date format was not clear; I am fairly certain the intent was to refer to the date format used in HTTP/1.1, and certainly it seems sensible to keep the same format as the HTTP Date: header.

4. The example is not a valid HTTP-Date due to the use of UTC timezone; HTTP/1.1 states the timezone MUST be GMT.

I will submit a pull request with suggested fixes for these shortly.

---

Bitbucket status: closed

Bitbucket origin: issue 79

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2017-03-22

This pull request has my suggest changes:

https://bitbucket.org/openid/fapi/pull-requests/13/updates-to-x-fapi-customer-last-logged/diff

I'm happy to make an updates/corrections if anyone spots anything that could be further improved.

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2017-03-23

The date changes make sense to me.
I suppose the issue with login is that you may actually want to know the last interaction with a customer rather than when they last logged in.

For example, if a customer is actively using a web-app for a number of hours should you send the time they logged in or their last interaction with your service?

The EBA's regulatory technical standards talk about Account Information Service Providers (AISP) being able to access a customer's account up tim 4 times per 24 hours when the customer isn't present, but there is no limit when the customer is present. Some banks may require additional authorisation from the end-user when the AISP exceeds the 4 times a day metric to prove the customer is present, but others may choose to trust the AISP. The AISP would have to let the bank know whether the customer was present or not. This header could perhaps help with that? Or perhaps we need a more explicit header... any thoughts?

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2017-03-23

Thanks for your thoughts Dave!

I think, overall, I'm not actually too clear what the original intent behind this header was. It is optional for the client to send this header, though I guess some servers could require it.

Perhaps (assuming it is intended to capture login) x-fapi-customer-last-authenticated-date: might actually be a better name than my current suggestion.

It seems to me that 'customer is present' is rather vague. I would say it comes down to the reason the AISP is making the request - ie. are they making it to satisfy a direct request that the user has just done, or as part of (for example) a 4 times a day scheduled query. To me, that means an explicit 'x-fapi-customer-is-present: yes / no' is required, though I wonder if a more explicit 'x-fapi-request-made-by-customer' may be better, although somewhat clumsily named. That name may also imply a level of verification (that the user is actually the customer and not someone else sitting at the customer's PC) that does not exist, so perhaps something like 'x-fapi-user-initiated-operation'.

It would be good to hear other people's thoughts.

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2017-03-24

I like 'x-fapi-user-initiated-operation'
It would be good to understand the intent of x-fapi-customer-last-logged-time. I agree that x-fapi-customer-last-authenticated-date would be clearer.

Hopefully we can discuss on the next fapi call.

[bitbucket-import-issues]

Originally submitted by SaschaZeGerman (Sascha Preibisch) on 2017-03-28

I believe the idea of the header is the same as 'auth_time' in an id_token in openid connect (http://openid.net/specs/openid-connect-core-1_0.html#IDToken). The value should reflect the point in time when the user authenticated the last time. In order to re-use what already exists, maybe the header could be named: 'x-fapi-customer-auth-time'. I think '...-last-...' is redundant since auth-time would always be the last time anyways.
Now that I look at it, maybe even '...customer...' can be removed. Who else should have logged in?
As Dave said, maybe something to be discussed at the next FAPI call.

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2017-03-29

The conclusion from today's call was we should name it:

x-fapi-auth-date

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2017-04-04

Accepting pull request. Thanks.

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2017-04-06

Updates to 'x-fapi-customer-last-logged-time' client header

1. 'time' is renamed to 'date' for consistency with the HTTP Date: header

2. 'customer-last-logged' is changed to 'auth' to more correctly
   reflect the purpose of the header.

3. The reference to W3C date format is replaced with the HTTP/1.1 date
   format (I am fairly certain this was the intent, as the example is
   definitely not a W3C date which take the form '1994-11-05T13:15:30Z',
   and it seems best to be consistent with the HTTP Date: header)

4. Updated the example to be a valid HTTP-Date (timezone MUST be GMT).

closes #79

→ <<cset 313a608>>