Allow providing of proofing data (e.g. selfies / photos of credentials) during issuance without web views

[jogu]

We should extend presentation during issuance to use https://github.com/openid/OpenID4VCI/pull/509/files to allow further types of things to be requested - e.g. photos of physical mdl.

Also could need to be encrypted as per request from ISO, as TLS may be terminated before the request arrives at the entity that would decrypt.

Various USA states already have this in production today, and popping a web view doesn't really work on companion devices.

Initially this could just be a way to transfer this kind of data in an encrypted way, without specifying the types of data and how the issuer requests them (a mechanism like this is defined in 23220-3 already). 23220-3 already allows the items to be individually encrypted to potentially allow some encrypted by the wallet front end or backend.

[jogu]

Marked as 1.1 as I really don't think we should expand the scope of 1.0, but also this is likely a requirement if we want to avoid 23220-3 Annex C defining it's own encryption methods for this.

[jogu]

As per agreement on today's WG call - we don't have the implementation experience to define this before 1.0 goes for wglc / public review. It can be defined as a non-breaking extension in 1.1 in the worst case.

[tlodderstedt]

Clarifying questions:

1. Is the objective to be able to take a picture on the device where the wallet resides and send it to the issuer?
2. What is the protocol context? Is the issuer relying on classical OpenID4VP or DC API for its interactions with the wallet? I'm asking since we framed presentation during issuance for cases where the issuer does not use DC API.

[jogu]

Clarifying questions:

1. Is the objective to be able to take a picture on the device where the wallet resides and send it to the issuer?

As an example, yes. And in particular to be able to do that in a native ui (i.e. without resorting to a web view).

2. What is the protocol context? Is the issuer relying on classical OpenID4VP or DC API for its interactions with the wallet? I'm asking since we framed presentation during issuance for cases where the issuer does not use DC API.

I'm not sure I understand the question - one definite possible design is that this would be happening during the interactions with the new authorization challenge endpoint added in #509. OID4VP & DC API are not involved. The issuer could return an error like "selfie_required" in the initial call to the authorization challenge endpoint, and the wallet could respond by sending a jpeg to the authorization challenge endpoint.

[GarethCOliver]

To give a sketched solution:

the error contains:

client_evidence {
evidence_requests = [
{
type = "TYPE1"
params = { ... } // optional
},
{
type = "TYPE2"
params = { ... } // optional
}
...
]
}

then the response looks something like:

evidence = [
{
type = "TYPE1"
data = { ... }
} // optionally encrypted
{
type = "TYPE2"
data = { ... }
} // optionally encrypted
]

With the specifics of how this is collected an implementation detail. type is an extension point for ecosystems, though it'd be possible to also specify some canonical ones.

Example Reasons for using it:

Device Hardware Capabilities: (NFC for passport/Id card), Camera Document Capture
User Experience: Allows avoiding jarring redirect, process kills during long-running memory-intense evidence gathering, polished 'native' experience.

• This is where allowing a direct native DC API call would fall.
  Information the Wallet is better able to provide: Account take-over/risk signals are a good example here, which also have to be hidden from the client.

Things it should NOT be used for:
Fine grain/generic UI control (we shouldn't re-invent HTML, use a redirect if Issuer needs this)
Log-in (this should be done on issuer surfaces).

[jogu]

Discussed on today's WG call - given we still on work to do on the presentation during issuance PR that this would need to build on top of, it seems like we don't have time to do this - moving to 1.1.