`interaction_types_supported` should probably be a metadata param and a request param; currently it is the latter only

[awoie]

When reading the IAR section, it says the following:

interaction_types_supported: REQUIRED. Comma-separated list of strings indicating the types of interactions that the Authorization Server supports. The order of the values is not significant. The following values are defined by this specification:

openid4vp_presentation: Indicates that the Authorization Server supports an OpenID4VP Presentation interaction, as defined in Section 6.2.1.1.
redirect_to_web: Indicates that the Authorization Server supports a redirect to a web-based interaction, as defined in Section 6.2.1.2.

This section relates to the IAR request parameter (the Wallet provides), not to the AS metadata, hence should be updated accordingly as follows:

interaction_types_supported: REQUIRED. Comma-separated list of strings indicating the types of interactions that the Wallet supports. The order of the values is not significant. The following values are defined by this specification:

openid4vp_presentation: Indicates that the Wallet supports an OpenID4VP Presentation interaction, as defined in Section 6.2.1.1.
redirect_to_web: Indicates that the Wallet supports a redirect to a web-based interaction, as defined in Section 6.2.1.2.

Additionally, the original text above should be moved to a dedicated AS metadata section and registered with IANA.

[jogu]

Yeah, the first bit is definitely just a typo/oversight. I've opened #599 to fix that.

I think the system works without interaction_types_supported as AS metadata (it's fine for the Wallet to send values the AS doesn't understand), but I also don't object to having it as AS metadata (it'd mostly serve as indications to a Wallet developer attempting to integrate with that AS which values they might want to try and code support for).

[awoie]

Yeah, the first bit is definitely just a typo/oversight. I've opened #599 to fix that.

I think the system works without interaction_types_supported as AS metadata (it's fine for the Wallet to send values the AS doesn't understand), but I also don't object to having it as AS metadata (it'd mostly serve as indications to a Wallet developer attempting to integrate with that AS which values they might want to try and code support for).

IMO, an additional metadata would be required to make it easier to add future extensions. This would complement this proposal: #604

[awoie]

Yeah, the first bit is definitely just a typo/oversight. I've opened #599 to fix that.
I think the system works without interaction_types_supported as AS metadata (it's fine for the Wallet to send values the AS doesn't understand), but I also don't object to having it as AS metadata (it'd mostly serve as indications to a Wallet developer attempting to integrate with that AS which values they might want to try and code support for).

IMO, an additional metadata would be required to make it easier to add future extensions. This would complement this proposal: #604

The metadata param should not only indicate what the AS supports, but what it actually requires to complete the IAE flow. Something like:

• interaction_types_required: array of arrays where the first array provides alternatives (OR), and the nested arrays provide required types to satisfy the IAE flow, e.g., [ [ "redirect_to_web", "openid4vp_presentation" ], [ "redirect_to_web" ], ["new_extension" ]]

This is important to avoid dead end flows.

It is critical that this goes in to OID4VCI 1.0.

[jogu]

This sounds really complicated to me.

Can dead-end flows be avoided by the AS checking the interaction_types_supported the wallet supplies, and erroring (or immediately directing to web) if they are insufficient?

[awoie]

This sounds really complicated to me.

Can dead-end flows be avoided by the AS checking the interaction_types_supported the wallet supplies, and erroring (or immediately directing to web) if they are insufficient?

Would it make sense to have a dedicated error code in this case? I would assume that not in all cases, redirect to web would be possible to satisfy all requirements. I guess redirect to web could then display some error to the user why it failed, i.e., the wallet did not meet the requirements.

[jogu]

discussed on this afternoon's WG call; no one objected to having a specific error code for this case.