Presentation of non-mdoc credentials (e.g. sd-jwt vc) offline

[tlodderstedt]

We had a good discussion at IIW #39 about ways to enable offline presentation of non-mdoc credentials.
Options discussed:

• Extension of ISO 18013-5
• Pursue OID4VP over BLE
• Use CTAP/HYBRID as transport for OID4VP requests and responses.
  The consensus in the session was the CTAP/HYBRID seems to be the most attractive approach as it leveraged CTAP/HYBRID (implementations and community and roadmap) and also leverages OID4VP feature for offline (e.g. transaction data).

Note: CTAP/HYBRID sends the data over the internet (via a relay server). Plan is to extend it with BLE and UWB. That would enable real offline presentation.

What we actually need is an appendix in OID4VP describing how CTAP could be used to pass OID4VP requests and receive respective responses. It should then work with all transports (even UWB going forward).

[c2bo]

My current understanding would be this:

We have a similar problem as we have with the Digital Credentials Browser API, where an extension to CTAP needs to be defined that would allow for an OpenID4VP Request to be conveyed using proximity protocols. Currently exists support for the DC API in Hybrid mode with the following supported flows that are relevant for credentials:

• dcp | credential presentation (Digital Credentials API)
• dci | credential issuance (Digital Credentials API)

Hybrid mode = flow where proof of proximity (e.g., BLE beacon) and data transport (e.g., tunneled over the internet) are decoupled.

For the feature discussed in this issue, we would need support for something similar, where data is transported using the proximity protocols (NFC, BLE, UWB, ..) as well instead of tunneling through the internet. Currently communicating directly over BLE also requires persistent pairing for both parties in CTAP (which makes a lot of sense in the scenarios authenticators are currently used).

---

I think this would make sense:

• OpenID4VP defines a profile for flows over a secure transport protocol (without expecting any kind of online connection). This should be pretty similar to the current DC API profile. We could adjust the current DC API profile to allow for the different modes of wallet invocation / origins and then have 3 subsections for:
  • Invocation over browser API (origin = website as provided by the browser)
  • Invocation by another APP (origin = origin app)
  • Invocation via CTAP "offline" (origin = physical transport; not sure what to best put here - just an identifier for the used transport protocol?)
• CTAP defines how to create an ad-hoc secure transport channel (without requiring pairing) and defines how the OpenID4VP messages are transmitted (with some kind of identifier for the protocol) - this could just be an extension to hybrid mode with new modes
  • additional initiation: NFC
  • additional transport: NFC(?) - do we want this?
  • additional transport: BLE
    ... Wi-Fi direct, UWB, or whatever technologies might make sense

Does this make sense? Especially to the people present at the discussion at IIW @ve7jtb @leecam @tlodderstedt @hlozi @Sakurann?

[awoie]

I'm not clear why we would need to define anything in OIDVP/OID4VCI to support these extended usages of CTAP with the Digital Credentials API? Shouldn't OID4VP/OID4VCI be agnostic to the actual initiation and transport of the Digital Credentials API?

[c2bo]

I'm not clear why we would need to define anything in OIDVP/OID4VCI to support these extended usages of CTAP with the Digital Credentials API? Shouldn't OID4VP/OID4VCI be agnostic to the actual initiation and transport of the Digital Credentials API?

That is imho one of the decisions we need to make and currently discussed in https://github.com/openid/OpenID4VP/pull/337/files#r1850770883 - there is a difference in the "type" of origin and we either need to generalize origin or create different origin-specific types.

[Sakurann]

note from #382 (comment) to update definition of Origin once this mechanism becomes available