[OpenID4VP] Wallet Instance metadata discovery

[Giuseppe De Marco]

In Section 8.2 - “ 8.2. Obtaining Wallet's Metadata “ we read

Verifier utilizing this specification has multiple options to obtain Wallet's metadata:

- Verifier obtains Wallet's metadata dynamically, e.g., using [RFC8414] or out-of-band mechanisms. 
  See Section 8 for the details.
- Verifier has pre-obtained static set of Wallet's metadata. See Section 10.1.2 for the example.

at the implementation level I am looking for a solution to satisfy the following requirement:

The Relying Party must obtain the Wallet Instance metadata in the form of a verifiable attestation issued by a trusted third party (Wallet Instance Attestation issued by the Wallet Provider), before it emits the request object.

The requirement is motivated by the RP that must known the wallet instance metadata, supported algs, supported credential formats, response_types_supported, request_object_signing_alg_values_supported.

considering that RFC8414 should not be applied, since it would force the wallet provider to publish the wallet instance metadata (or wallet instance attestation).

considering that an out of band mechanisms should be explorated, as also the strategy to pre-obtain the static wallet metadata/attestation.

in my team there is a tendency to use the request_uri endpoint as a vehicle for forwarding the wallet instance attestation, accompanied by a client_assertion that proves possession, vit HTTP POST, making the RP to issue the request object after having processed the wallet instance attestation.

This is undoubtedly non-standard, the request_uri being an protected endpoint and only consumable via HTTP GET.

I ask the working group for an idea, a vision, an alternative that can contribute to the specification or only to the satisfaction of the requirement without any improper adoption of the standards.

‌

[Giuseppe De Marco]

an alternative would be getting the request_uri with HTTP GET and including the wallet instance attestation as Authorization DPoP token and a DPoP proof as HTTP headers for the proof of possession of the wallet instance attestation.

[Torsten Lodderstedt]

Can you pleas shed some light on why the wallet metadata must be asserted by a third party? I’m asking since metadata typically is configuration/capability data that the respective provider publishes itself.

[Giuseppe De Marco]

Thank you for asking, here some objective assumptions:

• the Wallet Instance supports SIOPv2, so it is a provider
• the Wallet Instance supports OpenID4VP, so it provides presentations
• there are sign and enc algs, methods and endpoints, involved during the presentation phase
• the metadata is the artifact we traditionally use for having the capabilities of an entity, according to a format

there some open points to be addressed:
- in the wallet ecosystem trust models, there come the requirement of the Wallet Instance Attestation for attesting the device security according to a trust framework
- the wallet instance attestation must be provided to a credential issuer for the issuance of a digital credential
- the wallet instance attestation should be provided to a RP as well, to let it know the wallet security levels, and technical capabilities such the supported algs, url scheme and the revocation status list of that attestation
- the RP should obtain these information before (metadata discovery) issuing the request object

the metadata can be:

• published by a trusted entity
• published by the entity itself
• signed by a trusted entity and then published by the entity itself (as the Wallet Instance Attestation)
• published by the entity itself and verified with a mechanisms that involves trusted third parties and cryptographic bindinds (X.509 chains, OIDC Federation chains …)

regardless of the model used and the publication mechanism, this issue wants to identify the the way the metadata discovery can be done, without relying to abstract out of band or out of scope weak pointers.

the proposal is to allow forwarding of the attestation/metadata to the request_uri endpoint, or the definition of a new endpoint RP side for this scope.

For the first solution, related to the request_uri endpoint, it is necessary to provide a token, and the WAI is a token.

let's talk about it, let's understand together how to proceed

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VP