Do we need to support signed Credential Offer?

[Torsten Lodderstedt]

The data is currently sent plain over the wire without any means to ensure authenticity. The spec states

The Wallet MUST consider the parameter values in the initiation request as not trustworthy since the origin is not authenticated and the message integrity is not protected. The Wallet MUST apply the same checks on the Credential Issuer that it would apply when the flow is started from the Wallet itself since the Credential Issuer is not trustworthy just because it sent the initiation request. An attacker might attempt to use an initation request to conduct a phishing or injection attack.

The Wallet MUST NOT accept Credentials just because this mechanism was used. All protocol steps defined in this draft MUST be performed in the same way as if the Wallet would have started the flow.

We could add the option to sign the IIIR to provide a means to authenticity and tamper evidence.

[David W Chadwick]

I don’t think signing the IIR message provides much additional security if we say that the IIR should be obtained via TLS or air (QRcode) since the IIR is already being displayed on a web page protected by the issuer.

If the user is socially engineered to go to the wrong issuer website (e.g. Opera.com instead of 0pera.com) then the fake web site will publish fake metadata with a fake jwks_uri so the wallet would pick up the wrong public key and still validate the signed IIR. So signing the IIR has not bought us anything in this case.

[Kristina Yasuda]

+1

I do not see the need to sign IIR.

[Michael Jones]

As Torsten said on today’s call, signing the request would enable authenticating the requester.

[Kristina Yasuda]

discussed at Nov-10-2022 call, Torsten also suggeted that if we say IIR is not signed, we should drop two paragraphs he is quoting - agreed to give people time to think about it.

[Daniel Fett]

My thoughts:

• Signing the request allows authenticating the party that created the request (not necessarily the party actually sending the request).
• The meaning of this authentication depends on the ecoystem this will be used in. I assume that some ecosystems will have a strict policy on who can participate (e.g., banking) and therefore the parties that are able to sign something are somewhat trusted not to attack other participants. In other ecosystems, there will be less mutual trust and the importance of the signature will be lower.
• A signature can ensure freshness of the III-request: An attacker could try to replay III-requests (or create requests) in order to overload end-users (essentially DoS) with prompts from their wallet. If signatures are required, attackers cannot sign requests and replay is limited somehow (jti? exp?), the signature helps to mitigate this attack.
• Signatures may be interesting for auditability and non-repudiation, but I’m not sure if these are real requirements.

‌

[Kristina Yasuda]

if the purpose is to authenticate the issuer, I think without signing the request, credential_issuer in the offer becomes the only way to establish trust in the issuer - i think the only mechanism this excludes is the usage of x509s, so might not be the problem.

there is no wallet-provided nonce in the credential offer so even if it is not signed, to daniel’s point that Signing the request allows authenticating the party that created the request (not necessarily the party actually sending the request). we will hit the same limitations as those raised in the issue #1807.

I don’t remember why it was suggested to drop two paragraphs quoted if we decide to keep offer unsigned - I think these two paragraphs provide a lot of clarity and should be kept. tho maybe adding a paragraph saying “credential_offer“ identifier can be used to authenticate the issuer might be added.

[Kristina Yasuda]

(might be a separate issue but..) if we go unsigned path, something like below needs to be added to the spec from our implementation experience:

Note: RFC 9101 might suggest the usage of application/jwt media type in the response so that the URL-safe claims representation and processing can be the same in both the signed and unsigned cases as described in RFC 8725. However, since Credential Offer cannot be signed, application/json media type is used for simplicity and to avoid using "alg": "none".

‌

[Oliver Terbu]

+1 to adding such a note.

[Kristina Yasuda]

PR #570.

[Kristina Yasuda]

also during the discussion at OSW, based on Fabian’s formal security analysis, we discussed that signing CO will not prevent any of the identified attacks.

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VCI