Add support for issuing a VC into LCW via CHAPI

[dmitrizagidulin]

Add support for issuing a VC into LCW via CHAPI

History

December 2022

Support for issuing a VC from a mobile browser into LCW was added, using CHAPI + WebShare API.

It was tested as working on Android, in Build 52. But had a bug in the iOS workflow (you could only issue to LCW on iOS if you went through the workflow twice).

However, this method (using WebShare) turned out to be difficult for implementers to work with, so the CHAPI Mediator decided to take a different approach, and eventually disabled support for WebShare. But see below.

Present day (September 2023)

Currently, the CHAPI Mediator / Wallet Selector has support for mobile wallets using a different mechanism -- that of Universal app links. So, a bit more work is needed to add support for this new approach to LCW:

• Add a 'Register Wallet' screen to the wallet setup wizard. Status: DONE (see PR Register Wallet installation step added (issue #457) #488 )
• Issue #505 - Register a Universal app link for LCW, with Apple and Google. (by uploading a JSON object to the LCW site)
• LCW.app issue #10 - Add a 'register-wallet.html' page to the LCW site.
• Update the deep link handler on LCW to handle the new params.

[jchartrand]

@dmitrizagidulin

Question about that fourth todo ("Update the deep link handler on LCW to handle the new params"):

The current deeplink handling in the LCW accepts the deeplink and immediately posts a DIDAuth back to the issuer (using the request_url), getting back in return the signed VC.

The "Integrating with the VC-API Exchanges workflow" section of the CHAPI playground FAQ (https://chapi.io/developers/playgroundfaq/) also recommends doing it that way: pass a DIDAuth VPR via a chapi.get and let the wallet immediately post the DIDAuth VP, getting back in return the signed VC.

But you and I had talked about implementing a two stage interaction where either the deeplink or the chapi.get would first pass a VPR to the wallet asking the wallet to first hit the 'initiation' endpoint, which would then return another VPR asking for the DIDAuth. The wallet would then reply with the DIDAuth (posting it to the 'continuation' endpoint) and get back in return the signed VC.

So two questions:

1. Are we planning to (at least for now) implement only the single stage approach - passing in the DIDAuth VPR directly with a single initial CHAPI.get?

2. Whether we pass the DIDAuth VPR in directly, or indirectly after initiation, does the following DIDAuth VPR seem right? It is taken from that same CHAPI playground FAQ:

  "query": {
    "type": "DIDAuthentication"
  },
  "interact": {
    "service": [
      {
        "type": "VerifiableCredentialApiExchangeService",
        "serviceEndpoint": "https://playground.chapi.io/exchanges/eyJjcmVkZW50aWFsIjoiaHR0cHM6Ly9wbGF5Z3JvdW5kLmNoYXBpLmlvL2V4YW1wbGVzL2pmZjIvamZmMi5qc29uIiwiaXNzdWVyIjoiZGIvdmMifQ/esOGVHG8d44Q"
      },
      {
        "type": "CredentialHandlerService"
      }
    ]
  },
  "challenge": "g2Wvqg7-cQGWYCCH55rUl",
  "domain": "playground.chapi.io"
}

[kayaelle]

@dmitrizagidulin - do we need an issue for: "Update the deep link handler on LCW to handle the new params"

[alexfigtree]

Checked on latest build 58 in store, is working, closing.