Verifier Attestations reference/.well-known

[Alen Horvat]

Verifiers might have one or more VCs attesting their identity/right/obligations (issuers might be different).

When VCs are issued to DIDs (probably works also with other client id schemas), it might be enough that the request object is signed and the wallet may obtain the Verifier attestations from a well-known endpoint of the verifier (signed request object acts as a proof of possession) and since attestations are issued to the same DID, additional VP might not be required.

Is it of interest of the WG to consider this as an alternative next to the existing way of retrieving the Verifier Attestation?

[Oliver Terbu]

Is there a mechanisms that already exists that would allow the wallet to obtain the Verifier Metadata from a .well-known URL? I guess this can be done by using the `client_metadata_uri` parameter which allows the verifier to provide their metadata in the authorization request.

Alen, would client_metadata_uri help with your use case?

[Alen Horvat]

In simple cases, yes, in more complex cases no.

When verifier is always asking the same claims (only 1 scope exists), then the VCs can be in the metadata since the information is static.

However, when verifier app is more elaborate and supports different user types, it may select which VCs to share. In this case the VC selection is dynamic and depends on the scope. Would like to see if there are other use cases that identified similar requirements.

[Kristina Yasuda]

client_metadata_uri does not have to be static.

How I have seen people solve the issue you are describing is by putting a URL of an endpoint where verifier attestations are hosted into a DID Document’s service endpoint. in which case client_id_scheme is still did and a profile can define how to use a service endpoint in a DID Doc

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VP