iss value to be used in signed requests is not clear?

[jogu]

Feedback based on testing verifier conformance tests - I think it's not clear what the value for iss should be in signed request objects.

JAR only says:

If signed, the Authorization Request Object SHOULD contain the Claims iss (issuer) and aud (audience) as members with their semantics being the same as defined in the JWT [RFC7519] specification.

But doesn't actually say what value to give to iss.

I believe it can only sensibly be client id. That's certainly the approach that ended up being taken in FAPI conformance tests.

[bc-pi]

I believe [iss] can only sensibly be client id.

That seems sensible but begs the question of why have an iss claim at all that'll just have duplicative info?

And I'm not sure there are sensible things to use as an aud value...

[jogu]

I don't really know the background of the 'should' in JAR...

Actually I think iss is the only problem. https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#name-aud-of-a-request-object has text for aud. I'll update the issue title.

[bc-pi]

Actually I think iss is the only problem. https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#name-aud-of-a-request-object has text for aud. I'll update the issue title.

Indeed it does. Apologies I missed that. I thought that text was (only) in SIOP v2.

[jogu]

I checked ISO 18013-7 and interestingly it omits any mention of iss so people following that spec probably aren't including iss.

The VP conformance tests for wallets also haven't been sending iss in the request object (probably this was just accidental) and no one has complained so it seems wallets generally aren't requiring iss.

I think this emphasises that the question Brian asks above is a good one:

why have an iss claim at all that'll just have duplicative info?

[c2bo]

Hmm, following that discussion and given that JAR has a "SHOULD" there, it sounds like we should say something along the lines that in the scope of OpenID4VP iss is redundant with client_id and implementations must ignore iss if present?

Or do you think it makes more sense to add a MUST NOT be present here that might break some implementations?