Make auth_session optional if other binding mechanism exists.

[fkj]

The auth_session parameter is not needed in the all Interaction Required Responses since some interaction types already include a way to associate the next request with the ongoing auth sequence.

This makes the requirement for auth_session conditional on there not being some other mechanism for binding the request to the auth sequence.
It also adds a description of why the auth_session is not necessary in the redirect_to_web case and the custom example.

This is a suggestion to fix #690, but we could also go other ways.

[Sakurann]

i like the direction. I think we need to specify behavior for the wallet and explicitly say that the wallet must include auth_session in the subsequent request if it was included by the issuer in the IAE response. I didn't see us say something like that already, but i might have missed.

this means that it is completely up to the issuer to bind these sessions and these session binding is opaque to the wallet. i assume that's ok and does not open any security gaps as we have discussed this in the WG calls number of times, but wanted to note it one last time.

[fkj]

i like the direction. I think we need to specify behavior for the wallet and explicitly say that the wallet must include auth_session in the subsequent request if it was included by the issuer in the IAE response. I didn't see us say something like that already, but i might have missed.

I thought about adding this, but couldn't find a good way to phrase it/place to put it. Suggestions from the WG very welcome.

this means that it is completely up to the issuer to bind these sessions and these session binding is opaque to the wallet. i assume that's ok and does not open any security gaps as we have discussed this in the WG calls number of times, but wanted to note it one last time.

Yes, I think this is basically already the case. It makes sense to me that the issuer should be concerned about making sure the requests are all related to the same session whereas the wallet should not really care from a security perspective.

[jogu]

Discussed on today's WG call:

Could we be more explicit that each interaction type must state whether auth_session is included in the response or not?

[fkj]

How about adding this text in the iae-custom-extensions section:

A definition of a custom type of interaction MUST include exactly one of the following:

1. A normative requirement that the auth_session key MUST be included in the Interaction Required Response.
2. A definition of a mechanism to associate the next request by the Wallet with the ongoing authorization request sequence.

I know this is a little bit meta since it imposes requirements on the normative text of extension specs, but I guess that was your intention here @jogu?

[jogu]

Discussed on today's WG call - no objections to the approach @fkj suggests, let's try updating the PR and get some reviews.

[Vanderkast]

Should we normatively say what do the Wallet MUST (or MAY) do when it receives unexpected auth_session according to the interaction?

E.g. when AS adds auth_session in redirect_to_web interaction required response, the Wallet:
a) ignores that and goes with the redirect;
b) aborts auth process;

[fkj]

I think this should be up to each interaction type to define, but I don't have a strong opinion. Perhaps there is some interaction type where it makes sense to get either. I will update the PR to reflect what I think is the current consensus and we can go from there based on reviews.

[Vanderkast]

Suggested change

	* `auth_session`: REQUIRED. String containing a value that allows the Authorization Server to associate subsequent requests by this Wallet with the ongoing authorization request sequence. Wallets SHOULD treat this value as an opaque value. The value returned MUST be distinct for each interactive authorization response.
	* `auth_session`: REQUIRED under conditions defined by the interaction type. String containing a value that allows the Authorization Server to associate subsequent requests by this Wallet with the ongoing authorization request sequence. Wallets SHOULD treat this value as an opaque value. The value returned MUST be distinct for each interactive authorization response.

[fkj]

Another option:

Suggested change

	* `auth_session`: REQUIRED. String containing a value that allows the Authorization Server to associate subsequent requests by this Wallet with the ongoing authorization request sequence. Wallets SHOULD treat this value as an opaque value. The value returned MUST be distinct for each interactive authorization response.
	* `auth_session`: REQUIRED if specified by the interaction type. String containing a value that allows the Authorization Server to associate subsequent requests by this Wallet with the ongoing authorization request sequence. Wallets SHOULD treat this value as an opaque value. The value returned MUST be distinct for each interactive authorization response.

[fkj]

@Vanderkast Would you be OK with going with my suggestion for this one or do you have a strong opinion on the exact wording?