Should the verifier stop issuer key discovery if they already got one that worked for them?

[awoie]

If the verifier supports multiple different ways of issuer key discovery, the spec currently suggests that they would need to perform all of these different ways to validate the public key. Perhaps this is a good thing, but perhaps this is an unnecessary thing? Especially if the verifier supports HTTPS and X.509, should they do both?

[bc-pi]

In my thinking, one good/working key validation/discovery is all that's needed. But, looking again, I can see how https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-08.html#section-3.5 could be read as saying to always* do both.

So I would say it's unnecessary and we need to clarify or qualify that text.

* if as a verifier you support both

[bc-pi]

Wondering, assuming really, that this came about from this https://mailarchive.ietf.org/arch/msg/oauth/oRhW0bxoDrel1mnDJR_rokHq85I/

[awoie]

Wondering, assuming really, that this came about from this https://mailarchive.ietf.org/arch/msg/oauth/oRhW0bxoDrel1mnDJR_rokHq85I/

Indeed, it was inspired. I was supposed to send to the mailing list but then only replied individually.

[alenhorvat]

Signature validation key discovery and resolution mechanism is in most specifications defined by the signature profile and in the VC it must be unambiguous which mechanism should be used. If the mechanism is not unique (e.g., there are 3 ways to resolve the keys) and the issuer is supporting only one, two other mechanisms could be misused by an attacker

[babisRoutis]

Hi @awoie , @bc-pi

I was wondering the same. Have implemented this as follows:

Supported Method (Wallet/RP)	iss	Method Used
issuer metadata	HTTPS	issuer metadata, using kid if presented
x5c	HTTPS	x5c (SAN DNS or SAN URI), if x5c present
x5c & issuer metadata	HTTPS	x5c if there is x5c, metadata otherwise
did (outside of sd-jwt-vc scope)	DID	did, using optionally kid (DID URL) if present

In all cases, at most one method is used, with no fallback on error.

Given that if x5cmethod is eligible, then issuer metadata is eligible, I think that the former (x5c) must take precedence, if verifier/wallet support both.

[bc-pi]

Given that if x5cmethod is eligible, then issuer metadata is eligible, I think that the former (x5c) must take precedence, if verifier/wallet support both.

I think that's very reasonable @babisRoutis but the text in the draft needs some work and I'm sure could reasonably be interpreted differently. And there was some support/suggestion in yesterday's interim around having some explicit signal. Which probably/might have some relation to the concerns here https://mailarchive.ietf.org/arch/msg/oauth/ho6D8dc_7GQgJxwycS7khTM9_qw/. Some more thinking and/or work is needed in this area.

[babisRoutis]

Given that if x5cmethod is eligible, then issuer metadata is eligible, I think that the former (x5c) must take precedence, if verifier/wallet support both.

I think that's very reasonable @babisRoutis but the text in the draft needs some work and I'm sure could reasonably be interpreted differently. And there was some support/suggestion in yesterday's interim around having some explicit signal. Which probably/might have some relation to the concerns here https://mailarchive.ietf.org/arch/msg/oauth/ho6D8dc_7GQgJxwycS7khTM9_qw/. Some more thinking and/or work is needed in this area.

@bc-pi Thanks for sharing this.
Hope that this will not end up with issuer_id_scheme 😄