Verifier Attestations reference/.well-known
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?
Comments (5)
-
-
reporter 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.
-
- changed status to new
-
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 -
- changed status to resolved
Migrated to GitHub
- Log in to comment
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?