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

[Torsten Lodderstedt]

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.

[Daniel Fett]

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.

[Joseph Heenan]

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).

[Daniel Fett]

Waiting for Issue #282.

[Daniel Fett]

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

[Dima Postnikov]

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

[Dima Postnikov]

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?

[Joseph Heenan]

Yeah, I think this can be closed.

[Dima Postnikov]

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?

[Joseph Heenan]

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.

‌

[Dima Postnikov]

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.

[Joseph Heenan]

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.

[Nat Sakimura]

Need a PR.