Add verified endpoint functionality and simplify QR code data model & scanning workflow

[thobson88]

Verified endpoints are URLs contained in the serviceEndpoint field in a DID, where the DID has been verified (via the usual Trustchain mechanism).

This functionality provides a way to tackle "QR code scams", in which a malicious URL is QR-encoded and displayed in a location where people can be expected to mistake it for a genuine QR code (e.g. in a car park or at an electric vehicle charging point where online payments are required).

The mobile app already verifies URL endpoints used for credential issuance, so this is a relatively small change that generalises the existing functionality to any service endpoint.

This also provides an opportunity to clean up the QR code scanning logic in lib/app/pages/qr_code/bloc/qrcode.dart and improve the QR code data model itself, which should be better aligned with the W3C DID specification.

Steps:

• [x] create new QR codes using the new data model (see below)
• [x] implement the new logic in qrcode.dart and scan.dart

[thobson88]

Proposed new QR code data model

• assume the QR code contains a "did-url" identifying a service
  • we can do this because it must refer to a DID (otherwise it's not using Trustchain)
• so every Trustchain-readable QR code except for TinyVP (see below) looks like the following:

  {
  "did": <DID>
  "service": <SERVICE ID>
  "relativeRef": <OPTIONAL>
  }

  where the relativeRef is optional and used for identifying a specific resource (see https://www.w3.org/TR/did-core/#did-url-syntax).

The trustchain-mobile app does the following on reading one of these QR codes:

• resolve & verify the DID
• construct the target URL by:
  • get the service endpoint referred to by the "service" element (this is the "id" element in the DID service)
  • if the "relativeRef" element is present, append it to the service endpoint
  • return that URL

With this approach we don't need a "type" parameter in the QR code (which is Trustchain-specific, and creates a name conflict with the DID standard because services also have a "type"), so the app could read any QR code that conforms to the DID standard.

Example: The DVLA issuance QR code (see DVLA-issuance-qr.png) was previously this:

{
  "did":"did:ion:test:EiBbfqkfV53r3KKgW5sSYxDS61Zb4apJU4YOWbKFMrdhNw",
  "route":"/vc_rss/issuer/",
  "id":"c3e199ae-594b-11ee-b375-6af6d5dd6607"
}

(note that the service ID #TrustchainHTTP is currently hard-coded in qrcode.dart so doesn't appear in the QR code(!)) and becomes instead this:

{
  "did":"did:ion:test:EiBbfqkfV53r3KKgW5sSYxDS61Zb4apJU4YOWbKFMrdhNw",
  "service":"TrustchainHTTP",
  "relativeRef":"/vc_rss/issuer/c3e199ae-594b-11ee-b375-6af6d5dd6607"
}

Tiny VP

This is a special case to be handled separately. Instead of:

{
  "type":"TinyVP",
  "data":"H4sIAAAAAAAAA7VX21IbSRJ9n69QMK82rqx76W...8GwBFU3x2DwAA"
}

this case can now be simplified to:

{
  "TinyVP":"H4sIAAAAAAAAA7VX21IbSRJ9n69QMK82rqx76W...8GwBFU3x2DwAA"
}

[thobson88]

Implementation

This is in progress on branch 88-qr-data-model.

Under the above data model, the logic inside qrcode.dart is simplified to the following:

// Decode the JSON string
try {
  final qrcodeJson = jsonDecode(event.data);

  // Handle the Trustchain-specific case of TinyVP.
  if (qrcodeJson.containsKey(Constants.tinyVP)) {
    yield handleTinyVp(qrcodeJson);
  }
  // Handle the generic case of a DID service.
  yield await handleService(qrcodeJson);

} catch (e) {
  print(e);
  yield QRCodeStateMessage(
      StateMessage.error('This QRCode does not contain a valid message.'));
}

Then, in general, the steps required to add support for a new type of service are:

• add a new enum variant inside ServiceType (which must match exactly the "type" of the service in the DID document)
• in the (new) handleService method in scan.dart, add the handling logic for the new service type.

Note that this involves editing scan.dart only (no changes are needed in qrcode.dart).

[thobson88]

Next step is to publish a dDID to represent a car parking company, downstream of dft.gov.uk (ideally with a tfl.gov.uk dDID in between the two), containing the following service:

    "services": [
        {
            "id": "payment-url",
            "type": "WebUrl",
            "serviceEndpoint": "https://payments.safeparking.co.uk"
        }
    ]

and then implement the handling logic in the placeholder method promptWebUrl, inside scan.dart.

[thobson88]

New dDIDs published:

did:ion:test:EiC8hnHRr8kZUFThypBKFsHuzY8jhs4KttnLeJymF-upRQ  https://www.tfl.gov.uk (downstream of DfT: did:ion:test:EiBUjEaDDN1ROq6WgtBgIqpQZAZRu5XKNroOshi_sIDzsw)
did:ion:test:EiCbLT4g0T6VQQ0sLjn5qhhyBjasfQu2j3fBNPTJTblq6w  https://www.safeparking.co.uk (downstream of TFL)

and new rogue DID:

did:ion:test:EiByIMb7iIuvToiU299nmRIS4oA3tjCN7mhARaeIdEQddA  https://www.saefparking.co.uk (downstream of no one)

[thobson88]

Done on branch 88-qr-data-model. Ready to merge.

The new file web_url_viewer.dart contains two blocks of code (currently commented out) specifically for the AI UK demo. These should be uncommented on a new demos/aiuk-showcase branch.

[thobson88]

All done, just needs merging.