Require use of (most of) FAPI2 with VCI

[jogu]

The requirements to use PAR and PKCE are already present in FAPI2 so can be removed here.

closes #198
closes #283

[Sakurann]

re PKCE and PAR

[jogu]

Discussed on today's WG call: Oliver to review then we'll merge.

[paulbastian]

FAPI seems to pull in some requirements like mTLS and specific TLS versions that many people implementing HAIP likely not support currently.
At the same time, some things of FAPI do not apply well, e.g. OIDC, CIBA or are already defined in OpenID4VCI (e.g. RFC8414)
So I'm unsure if we do ourselves a favor of pulling in all of FAPI 2.0 or just re-phrase the relevant things in HAIP or reference specific sections of FAPI.

[jogu]

FAPI seems to pull in some requirements like mTLS and specific TLS versions that many people implementing HAIP likely not support currently.

The requirements are just the best current practices for TLS. If people implementing HAIP don't currently support at least TLS 1.2 and the IETF recommended ciphers, that's something those people really need to look at resolving.

At the same time, some things of FAPI do not apply well, e.g. OIDC, CIBA or are already defined in OpenID4VCI (e.g. RFC8414) So I'm unsure if we do ourselves a favor of pulling in all of FAPI 2.0 or just re-phrase the relevant things in HAIP or reference specific sections of FAPI.

CIBA isn't part of the FAPI2 Security Profile document that's linked to. OIDC isn't required by FAPI2 (and is barely mentioned).

Authorization Servers are not currently required to support RFC8414 by OpenID4VCI; mandating FAPI2 like this is HAIP will mean that HAIP compliant ASes (and OAuth Clients) are required to support RFC8414.

[jogu]

FAPI seems to pull in some requirements like mTLS and specific TLS versions that many people implementing HAIP likely not support currently.

Also just for clarity, this PR does not pull in any requirements for mTLS - the two places where mTLS is permitted in FAPI2 is for client authentication and for sender constraining of access tokens. For the former we say wallet attestations must be used, and for the latter we say dpop must be used, so mtls is never applicable.

[paulbastian]

I had a deeper look into FAPI 2 security profile, it doesn't seem as clear to me, so here are some considerations:

• Section 5.1.2 states: "However, for a profile to be compliant with this document, the profile shall not remove or override mandatory behaviors, as doing so is likely to invalidate the formal security analysis and reduce security in potentially unpredictable ways." -> unclear if we can apply this with making changes
• Section 5.2 Network layer protections, VCI and VP already point to BCP195, isn't that enough?
  • I would not want to mandate MTLS
• Section 5.3 listing 9 technologies from which 2 not apply and 3 are already defined by VCI and VP itself, so this is only about DPoP, PKCE, PAR and RFC9207
• Section 5.3.2.1 most of these points are already defined within VCI / VP or do not apply imo
• Section 5.3.2.2 most of these things do apply, this seems like the most helpful section, maybe reference this one directly or copy the relevant points to HAIP?
• Sections 5.3.3 for clients are very similar to points above
• Section 5.4 on cryptography, this is an open point, I believe we will end up with a different choice than FAPI
• some parts are mentioning OIDC, which also do not apply
• people are already arguing that our ecosystem consists of too many standards to comply to, mandating FAPI 2 Security profile seems to feed this argument, while we also have define exceptions on top
• how many implementations do we have that are fully compliant to this?

tldr: I would rather define our requirements for DPoP, PKCE, PAR and RFC9207 in HAIP, maybe mention FAPI2 as SHOULD for additional considerations

[jogu]

I had a deeper look into FAPI 2 security profile, it doesn't seem as clear to me, so here are some considerations:

• Section 5.1.2 states: "However, for a profile to be compliant with this document, the profile shall not remove or override mandatory behaviors, as doing so is likely to invalidate the formal security analysis and reduce security in potentially unpredictable ways." -> unclear if we can apply this with making changes

Thanks Paul. Our profile would not be compliant with FAPI (because of the requirement to use client attestations). (I've suggested to FAPI WG that a later revision of FAPI could allow the use of client attestations, which may mean we are, at some later point in time, entirely compliant.)

• Section 5.2 Network layer protections, VCI and VP already point to BCP195, isn't that enough?

Generally no - a lot of the points are covered by BCP 195, though some ('should' use DNSSEC, and I think 1 or 2 others) aren't covered.

• I would not want to mandate MTLS

Agreed. Although our experience with FAPI is that people do tend to mandate MTLS on top of protocols that don't strictly need it so I suspect some people (particularly when doing server to server) will do it and that section of FAPI provides some guidance on how to di that in an interoperable manner.

• Section 5.3 listing 9 technologies from which 2 not apply and 3 are already defined by VCI and VP itself, so this is only about DPoP, PKCE, PAR and RFC9207
• Section 5.3.2.1 most of these points are already defined within VCI / VP or do not apply imo

A lot of them aren't required in VCI/VP. e.g. the use of sender-constrained access tokens isn't required in VCI.

• Section 5.3.2.2 most of these things do apply, this seems like the most helpful section, maybe reference this one directly or copy the relevant points to HAIP?

I wouldn't want to copy, but referring to them is an option. It doesn't necessarily improve things without careful wording (e.g. the question "can I just use a FAPI compliant AS" becomes a lot harder to figure out the answer for).

• Sections 5.3.3 for clients are very similar to points above

Yes, deliberately so - both sides need to do the correct thing. That's the kind of thing the current HAIP text isn't very good at (e.g. it says both sides must support PKCE, but it doesn't require the AS to reject requests without PKCE).

• Section 5.4 on cryptography, this is an open point, I believe we will end up with a different choice than FAPI

We may need something here, agreed.

• some parts are mentioning OIDC, which also do not apply

Those parts are (or should all be) "if you are using OIDC, ....". So they're not harmful.

• people are already arguing that our ecosystem consists of too many standards to comply to, mandating FAPI 2 Security profile seems to feed this argument, while we also have define exceptions on top

I think the question is whether we want a similar security level to FAPI2 or not.
If we do, I honestly think the 'too many specs' argument isn't that relevant - it doesn't make a huge difference if we have roughly the same requirements split across two documents or all in the same document. And there's probably an argument for reusing an existing spec as much as possible.

• how many implementations do we have that are fully compliant to this?

I suspect zero - one of the battles in the interop testing was getting wallets to start doing PKCE for example, so I suspect live implementations are very rough and are not compliant with the current HAIP text even. That would actually be an argument in favour of using FAPI2, as it would mean a set of conformance tests could be shipped very quickly that'd give pretty decent coverage.

tldr: I would rather define our requirements for DPoP, PKCE, PAR and RFC9207 in HAIP, maybe mention FAPI2 as SHOULD for additional considerations

FAPI2 is already a SHOULD in VCI itself, so we wouldn't need to (and probably shouldn't) say that again in HAIP.

[jogu]

Discussed on today's EU working group call - consensus on the call to progress in this direction. But adding a note that the sections about openid and mtls probably aren't too important could help people. And we want to make sure we don't encourage the application of mtls everywhere.

Also we may need extra text about signing algorithms depending on conclusion of #112 - in particular if we end up allowing different for wallet attestation / proof / DPoP signing algs than the text here https://openid.net/specs/fapi-security-profile-2_0.html#section-5.4.1 :

PS256, ES256, or EdDSA (using the Ed25519 variant) algorithms

(The current HAIP text requires support for ES256 so no action needed right now I think.)

[jogu]

I've added a note about some parts of FAPI not being applicable as per discussion on yesterday's working group call. @paulbastian could you take another look and see if you're okay withdrawing your request changes please?

[paulbastian]

How about this?

Suggested change

	* MUST comply with the [@!FAPI2_Security_Profile], including but not limited to using PKCE [@!RFC7636] with `S256` as the code challenge method, Pushed Authorization Requests (PAR) [@!RFC9126] and the `iss` value in the Authorization response [@!RFC9207]. The following exception to [@!FAPI2_Security_Profile] applies:
	* Client authentication: Wallet Attestation as defined in (#wallet-attestation) in used.
	Note that some parts of [@!FAPI2_Security_Profile] are not required when using only OpenID for Verifiable Credential Issuance - there is no need to use MTLS or OpenID Connect.
	* MUST support PKCE [@!RFC7636], Pushed Authorization Requests (PAR) [@!RFC9126] and the `iss` value in the Authorization response [@!RFC9207] as defined in [@!FAPI2_Security_Profile]. ```

[jogu]

I've incorporated a suggestion based on @paulbastian wording, please recheck. (I didn't use the 'as defined in wording' as I think that resulted in it being arguable that other requirements in FAPI wouldn't apply, and I believe we do want those to apply.)

[Sakurann]

WG discussion:

• agreed to stick to a direction of listing what from FAPI does not apply to HAIP.
  • mainly @paulbastian, @bc-pi, optionally @danielfett @tlodderstedt @Sakurann to review what is to be excluded
  • crypto part is already noted by Joseph
• remove references to security BCP, because FAPI was created as an actionable alternative to BCP.

[Sakurann]

based on the WG discussion, would like to re read and undertand how to bring clarity

verbal agreement to dismiss