[OpenID4VP] Wallet Instance metadata discovery

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1967

Original Reporter: peppelinux

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.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

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

[alenhorvat]

+1 for this.

Original question:

I have a question wrt dynamic wallet-client metadata negotiation.

Most OID4VP flows will use the request_uri approach where the request object is fetched from the server.

In a basic authorisation request, Verifier presents its metadata (as value or as reference via client_metadata). Wallet could send its metadata to the request_uri endpoint and the server could generate a request that matches the Wallet requirements. Of course it is the server who defines the minimal requirements (wallet should not be able to downgrade the config from a security point of view)

Minimal assumption by the server would be the wallet authorisation endpoint.

Related discussion: https://github.com/openid/OpenID4VP/issues/45

POST authorization endpoint could solve the problem. In this case request_uri can be omitted. AS should, in the metadata, notify what information it accepts.

@peppelinux what you're describing is something that we covered: https://api-pilot.ebsi.eu/docs/ct/verifiable-presentation-exchange-guidelines-v3 and application of the flow is in the B2B VC exchange: https://api-pilot.ebsi.eu/docs/ct/verifiable-presentation-exchange-guidelines-v3; except that here we as for an id token, not a vp token.

Flow would essentially be: Wallet receives an authZ request (QR, redirect) Wallet calls the POST /authorisations endpoint to pass the wallet metadata; response is either: a) a request object if no additional info is required b) VP Token or ID token request, if RP requires additional data Wallet processes the request and shares sends required info (wallet/key attestation, other) (VP token response)

at the end of the VP flow, the wallet receives the authorisation request bound to the first call - optionally, the wallet could be sent back to the authorise endpoint (with a state-bound identifier)

[Sakurann]

Is this addressed by PR #45 that Alen linked above?

[peppelinux]

Resolved by https://github.com/openid/OpenID4VP/pull/59/files