x-fapi-interaction-id across client to AS and RS interactions

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2020-05-13

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.

---

Bitbucket status: open

Bitbucket origin: issue 290

[bitbucket-import-issues]

Originally submitted by Daniel Fett (Daniel Fett) on 2020-11-08

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.

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2020-11-09

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 header

is currently only a requirement on the resource server though (not on the authorization server).

[bitbucket-import-issues]

Originally submitted by Daniel Fett (Daniel Fett) on 2021-01-13

Waiting for #282.

[bitbucket-import-issues]

Originally submitted by Daniel Fett (Daniel Fett) on 2021-01-27

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

[bitbucket-import-issues]

Originally submitted by Dima Postnikov (Dima Postnikov) on 2022-08-08

I still like Torsten’s suggestion… Are we still planning to add this into Implementation and Deployment Advice?

[bitbucket-import-issues]

Originally submitted by Dima Postnikov (Dima Postnikov) on 2022-08-08

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:

1. 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;
2. 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;
3. participants (whether Client, AS or RS) shall log the value of x-fapi-interaction-id in the log entry.

This should be closed then?

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2022-08-08

Yeah, I think this can be closed.

[bitbucket-import-issues]

Originally submitted by Dima Postnikov (Dima Postnikov) on 2022-08-12

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 with x-fapi-interaction-id, makes a token request with x-fapi-interaction-id and, eventually makes an RS call with x-fapi-interaction-id.

Should it be the same x-fapi-interaction-id? Or all different? Or some different?

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2022-08-12

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.

‌

[bitbucket-import-issues]

Originally submitted by Dima Postnikov (Dima Postnikov) on 2022-08-15

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 different x-fapi-interaction-id for each of the API calls afterwards. Particular scenarios where same x-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.