OpenID4VPs: Offline Support
Issue #1561
closed
OpenID4VP needs support to present credentials via a near-field communication mechanism, if the wallet is offline (from the internet).
I assume a BLE connection bootstrapped via a QR code presented by the wallet might be a good starting point as it should work on iOS and Android.
Note: sub-sequently, we should add offline support to OpenID4VCI as well.
Comments (4)
-
-
reporter
I agree with the proposal to have a formal for request and response that can be used across different transport.
However, that’s not sufficient to actually implement a presentation process. That requires real transport, e.g. BLE, NFC, QR codes.
Defining it for BLE is a first step. I suggested BLE (with QR code for bootstrapping) since there is more support for it than NFC.
We can define further transports.
Simple QR codes are different as there is no request, i.e. no nonce and no audience. So I don‘t know whether is a response as well or whether the QR Code is nothing but the credential.
-
We could likely benefit from the lessons learned when developing the transport layers of CTAP2 https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html . Like is being proposed above, CTAP2 has both a transport-independent layer and a transport-specific layer.
-
- changed status to closed
merging the conversation into
#1499 - Log in to comment
- Assignee
- –
- Type
- Priority
- Status
- closed
- Component
- Verifiable Presentation
- Milestone
- –
- Version
- –
- Votes
- 0
- Watchers
- 1
I think we should avoid any particular technology here and just define a format for request and response.
For example, in Germany we had the verifier scan vaccination certificates as a QR code for the past year, and since the people here are already used to that procedure we probably want to support it.
In more complex scenarios, where the wallet needs to read in some presentation_definition (rather than the user knowing which credentials need to be presented), this method alone would mean two QR-code scans (holder scans request from verifier, verifier scans response), which may be inconvenient but still acceptible (and a transparent system may even help build trust in such a technology: “I know that my phone is simply responding to a single request”).
BLE is more convenient, but not supported by every phone. Technology X (tbd) may be more convenient still. But I think we should maintain a minimalistic list of direct dependencies in this spec. Since we are already using QR-codes, (if we really want to focus on one technology for interoperability,) we should stick with it and defer any other technologies to future specs.