Adds the ability to continue after redirect_to_web interaction on IAE

[tplooker]

Spun out of #509, this PR adds the ability to continue an authorisation process at the IAE after a redirect_to_web interaction.

Following feedback on the WG call i've added the requirement for PKCE in the event it was used in the initial request.

[Sakurann]

wg discussion:

• wg understands there is a need for this feature, but there is still uncomfortable-ness from security perspective, while there are mitigations being proposed as a starting point.
• could someone external to this group who has strong background in web security look into this?

[Sakurann]

wg discussion:

• no other implementers out of those present on the call
• doing this in 1.1 is an option. potentially can be cleanly extended in 1.1, using existing extension points, using a new type in IAE.

[tplooker]

doing this in 1.1 is an option. potentially can be cleanly extended in 1.1, using existing extension points, using a new type in IAE.

@Sakurann FYI this isn't an option for v1.1 as it would create a breaking change when redirecting back to the wallet. That is why it needs to be included in v1.0

[jogu]

doing this in 1.1 is an option. potentially can be cleanly extended in 1.1, using existing extension points, using a new type in IAE.

@Sakurann FYI this isn't an option for v1.1 as it would create a breaking change when redirecting back to the wallet. That is why it needs to be included in v1.0

I think the thought was that a new type could be defined that supported this; for example "redirect_to_web_version2" (though I'm sure we can come up with a better name).

The slight downside of how it is currently in this PR is that the wallet isn't permitted to opt in to the additional complexity. (Though maybe the additional complexity is small.)

I think the biggest worry is putting this in at the last minute (the vote announcement for VCI goes out on Thursday next week) and potentially missing security issues that mean we have to make breaking changes later - e.g. #595 only just came up for IAR in general.

[charsleysa]

I think this PR should be 1.0. The additional complexity is marginal if the wallet is already planning to support redirect_to_web.

The only thing I think maybe should be changed is that the status should also be included in the response (so status=ok for authorization code response and status=require_interaction for continuation).

From the security perspective, I don't see this being any more vulnerable than a typical authorization endpoint response and existing best practice mitigations should be sufficient.

[deshmukhrajvardhan]

Me and Andy-lim. Like the general direction of this PR .i.e. a mechanism for wallet to do a follow up request so that it can send multiple creds until Issuer is satisfied, before issuing it new creds.

Andy raised a good point that should there be some statement that talks about the case when code_verifier does not verify against the code_challenge.

Maybe something like:

If the code_verifier parameter is present in a follow-up request but the Authorization Server cannot successfully verify it against the original code_challenge (as defined in Section 4.6 of [@!RFC7636]), the Authorization Server MUST return an error response with the error parameter set to invalid_request and SHOULD include an error_description parameter indicating that the PKCE verification failed.

[javereec]

I support adding this to 1.0. We've encountered use cases in the past around workplace credentials where flows like these are very useful. Having a path to handle these (complex) interactions in a standardised way is good. I also agree with other commenters that allowing this doesn't seem to add more risk then was already there in the first place.

[tplooker]

I've made the following changes to this PR based on feedback

• Reverted the change from code -> authorization_code that was mistakenly introduced
• Updated the text (which was already inconsistent) to make it clear that the auth_session parameter value sent in follow up requests MUST always be the most recent one that has been obtained.
• Related to the above I've also updated the definition of the auth_session parameter value in the response to be unique for every response provided, I will explain below my rationale for this change.
• Removed a duplicated normative statement in the IAE response section.

Why auth_session should always be unique

IMO the original language in the follow up request implied this value could rotate in a given session, so to formalise this I've clarified that and also made it clear the value needs to be unique in each response.

By making auth_session unique there are several benefits.

1. Limiting the validity of any specific auth_session value. In complex authorisation workflows we ensure the auth_session value is not fixed across the entire session.
2. Mechanism for session state tracking for the AS. In complex multi-step authorisation workflows, it would be difficult for an AS to know what step a given session is in with a specific wallet instance by looking at the IAE request alone. By making auth_session unique in each response, this can be used by the AS to detect what state a given session is in.

[tplooker]

I think the thought was that a new type could be defined that supported this; for example "redirect_to_web_version2" (though I'm sure we can come up with a better name).

I don't think this is a viable solution, we just end up largely duplicating this mechanism here with 2% difference, thats likely to lead to its own security challenges.

The slight downside of how it is currently in this PR is that the wallet isn't permitted to opt in to the additional complexity. (Though maybe the additional complexity is small.)

To the contrary I don't think the wallet should be able to opt out here. Thats needless fragmentation which will just hurt interoperability. The complexity is also very low, a wallet supporting IAE will already know how to send a follow up request, all this PR does is detail how the wallet does this when receiving a new auth_session parameter from the Authorisation response.

[javereec]

I like the new additions. They make things more clear.

I made one very minor suggestion to differentiate between follow-up request and the (last) follow-up request.

[deshmukhrajvardhan]

Other than the 2 comments I've mentioned, which can be addressed editorially, this PR looks good to me.

[jogu]

Discussed on today's WG call - consensus to merge once above issues resolved. Joseph to check to see if Stuttgart team could have a very quick check.