[SD-JWT] High Assurance Profile of OpenID4VC with SD-JWT-VC

[peppelinux]

Issuance and presentation should be designed according to the drafts below:

https://github.com/vcstuff/high-assurance-profile https://github.com/vcstuff/draft-terbu-sd-jwt-vc

[fmarino-ipzs]

Regarding the differences between the IT Wallet profile for PID issuance and the OIDC4VC-HAIP, we provide the following summary based on our knowledge.

1. In the OIDC4VC-HAIP, the pre-auth code flow is mandatory for credential issuance. The IT Wallet profile doesn't support pre-auth code flow for security reasons.
2. The eudiw:// URL scheme is used instead of the haip:// URL scheme. If we fully adopt the OIDC4VC-HAIP, we will also adopt the URL scheme.
3. In the OIDC4VC-HAIP, the wallet instance must perform client authentication according to I-D.ietf-looker-key-attestation-client-authentication for PAR and token endpoint, while in the IT Wallet, we are currently considering RFC7521 for the PAR (see https://www.rfc-editor.org/rfc/rfc9126.html#section-2) and private_key_jwt for the token endpoint. However, we are open to adopting I-D.ietf-looker-key-attestation-client-authentication. We are currently analyzing the security differences between the two approaches.
4. Refresh tokens are not currently allowed in the IT Wallet for the PID issuance scenario as security analysis and design is required based on the level of assurance. Refresh tokens don't require user involvement. Therefore, privacy and security aspects should be further understood. For PID issuance, we require strong authentication and user involvement. We are open to considering RTs for other EAA use cases.

@peppelinux @asharif1990

[tlodderstedt]

re 1: Can you please elaborate on (1)? Also, do you support credential offer with authz code? re 3: Replay protection for RFC7521 relies on the jti, using a key bound attestation scales better. private_key_jwt requires a key pre-registered with the AS/OP for authentication, so I fail to understand how it works in an ecosystem setup and it does not allow to use a assertion issued by a 3rd party. https://datatracker.ietf.org/doc/html/draft-looker-oauth-attestation-based-client-auth combines both (as it has the assertion part from RFC 7523 and the key for proof of possession is asserted by a trusted third party). re 4: FYI - we are considering to remove the RT requirement from HAIP.

[fmarino-ipzs]

1 - in the current stage, we didn’t consider the pre-authorized code flow as it opens the door to phishing attacks and it still demands further security analysis to be sure that it doesn’t open doors to other security problems. Using the PIN could mitigate the replay attack (under a strong trust model assumption), but it still could be not enough for some social engineering attack scenarios (PIN phishing). The mitigation for this could be providing a mechanism to take confirmation from the user (Holder) - by showing the user the endpoint of the credential issuer - and, if the user confirms the endpoint, it will forward the PIN. Our concern is that the user is not always aware of what they click and may not pay too much attention to the final endpoint. As it is pointed out by the OIDC4VCI (Section 11.3) the Pre-Authorized Code by design it is not bound to a certain device (as the Authorization Code Flow does with PKCE). On the other hand, the authorization code flow has been out for a long time, and there are already many security analyses and best current practices for it. Regarding the credential offer, in the current version, we are focusing on the main functionalities but we will consider it in the next future.

3 - we already mentioned to you how our solution can avoid the replay here (https://github.com/italia/eudi-wallet-it-docs/issues/33#issuecomment-1625107250). It is possible to use the private_key_jwt at the token endpoint because at token request the AS/OP is already aware of the wallet instance client_id and the relevant public key (communicated in PAR request).

[peppelinux]

Resolved by https://github.com/vcstuff/oid4vc-haip-sd-jwt-vc/pull/56/files#diff-a99995e257fff0f7a2ffc150370efce1818b9c1622a50f0187b99e122fc24944R105

HAIP mandates the implementation of auth code flow, while the pre-authz code flow is out of scope for us

we look forward for an implementation of the credential offer flow using the auth code flow

[tlodderstedt]

@peppelinux why do you prefer authz code over pre auth code?

[peppelinux]

pre-authz code flow,

• is weak with shoulder surfing attacks;
• allows an user to share the qrcode and the pin to another user. There are criminal organizations that pay to obtain false documents and a technology that allows this kind of thing in a simple and remote way, without physical proximity, should not be used for government implementation profiles;
• Using PIN produces a worse UX than alternatives without this.

auth code flow,

• is consolidated over time by governative and financial grade profiles, like FAPI and OpenID Connect iGov;
• represents the most secure way to authenticate in the OAuth 2.0 and OpenID Connect ecosystem;
• it reuses endpoints and components already implemented in the previous infrastructure, eg: in italy we already use this flow.

[peppelinux]

Moved here https://github.com/italia/eudi-wallet-it-docs/issues/154