- edited description
x-fapi-interaction-id across client to AS and RS interactions
I suggest to discuss to broaden the scope of the x-fapi-interaction-id to also cover interactions with the AS, such as PAR, authorization request, token request. I think that would be very useful.
Comments (18)
-
reporter -
- changed component to FAPI2: Baseline
-
Current wording:
may send the `x-fapi-interaction-id` request header whose value is a [@!RFC4122] UUID to the server (...)
So PAR and token request are covered.
Sending it in the authorization request is tricky due to the nature of navigation with GET in browsers. I think that we don’t want to introduce a new authorization request parameter (outside of PAR) for this.
-
This requirement (and at least one other):
shall set the response header
x-fapi-interaction-id
to the value received from the corresponding fapi client request headeris currently only a requirement on the resource server though (not on the authorization server).
-
Waiting for Issue #282.
-
- changed milestone to 2nd Implementers Draft
-
Removed the x-fapi- headers in master pending further discussion after the 1st Implementer’s Draft
-
- changed component to Implementation & Deployment Advice
-
I still like Torsten’s suggestion… Are we still planning to add this into Implementation and Deployment Advice?
-
Oh wait. It’s there already for FAPI 2.
x-fapi-interaction-id
This header can be used to enable Authorization Servers, Resource Servers and Clients to better track and debug any issues between them. If an ecosystem adopts
x-fapi-interaction-id
then the following clauses apply:- clients shall send the
x-fapi-interaction-id
request header, the value shall be a RFC4122 UUID, e.g.,x-fapi-interaction-id: c770aef3-6784-41f7-8e0e-ff5f97bddb3a
; - the AS or RS shall set the response header
x-fapi-interaction-id
to the value received from the corresponding FAPI client request header or to a [RFC4122] UUID value if the request header was not provided to track the interaction, e.g.,x-fapi-interaction-id: c770aef3-6784-41f7-8e0e-ff5f97bddb3a
; - participants (whether Client, AS or RS) shall log the value of
x-fapi-interaction-id
in the log entry.
This should be closed then?
- clients shall send the
-
Yeah, I think this can be closed.
-
Now that we extended
x-fapi-interaction-id
from “Client - RS” interaction to “Client - AS - RS” interaction, could we clarify the following scenario:If a client calls a PAR endpoint with
x-fapi-interaction-id
, makes an authorisation request withx-fapi-interaction-id
, makes a token request withx-fapi-interaction-id
and, eventually makes an RS call withx-fapi-interaction-id
.Should it be the same
x-fapi-interaction-id
? Or all different? Or some different? -
I think it’s upto the client though I guess we could make a suggestion. I would expect that across a single authorization code flow the client would probably choose/want to use a consistent interaction id, but requiring it to use the same one if (say) it wants to use the refresh token grant / RS call days later in a different session with the user that’d seem like overreach.
-
Thanks Joseph, this in-between approach makes sense to me too. We could add a note to the text as following:
Option 1:
Note: Particular scenarios where same
x-fapi-interaction-id
is used across multiple calls are to be defined by implementers.Option 2:
Note: It is recommended to use the same
x-fapi-interaction-id
across single authorization code flow and differentx-fapi-interaction-id
for each of the API calls afterwards. Particular scenarios where samex-fapi-interaction-id
is used across multiple calls could to be defined by implementers.What do you think?
There is no impact to RS or AS, just for the client and the troubleshooting process in general.
-
It’d seem reasonable to offer a bit more advice on the subject.
I think we should avoid anything that might imply the AS can require particular behaviours from the client (i.e. the x-fapi-interaction-id header should never be grounds to fail an operation).
Probably for the purposes of making finding any particular set of transactions in logging possible one
x-fapi-interaction-id
per user session is fine (when combined with rough time + endpoint url), although I can imagine in some cases there might be a lot of calls to the same endpoint url in a short space of time that might make it worthwhile to use different interactive ids. -
Need a PR.
-
- changed status to open
-
-
assigned issue to
-
assigned issue to
- Log in to comment