Upon Scanning the QR Code in the iOS Wallet, the HC1 prefix is removed. The resultant QR Code that is saved in the Wallet is invalid, as it's missing the HC1 prefix.

in HCert.swift:

  static func parsePrefix(_ payloadString: String, errors: ParseErrors?) -> String {
    var payloadString = payloadString
    var foundPrefix = false
    for prefix in Self.supportedPrefixes {
      if payloadString.starts(with: prefix) {
        payloadString = String(payloadString.dropFirst(prefix.count))
        foundPrefix = true
        break
      }
    }
    if !foundPrefix {
      errors?.errors.append(.prefix)
    }
    return payloadString
  }

The above line removes the HC1 prefix (which is correct at this point) payloadString = String(payloadString.dropFirst(prefix.count))

However, later in HCERT+UIKit.swift, this HC1 is never returned to the payLoad when saving the new QR Code that is saved in the wallet.

  func makeQrCode() -> UIImage? {
    let data = payloadString.data(using: String.Encoding.ascii)

    if let filter = CIFilter(name: "CIQRCodeGenerator") {
      filter.setValue(data, forKey: "inputMessage")
      let transform = CGAffineTransform(scaleX: 3, y: 3)

      if let output = filter.outputImage?.transformed(by: transform) {
        return UIImage(ciImage: output)
      }
    }

    return nil
  }

Either we need to either prepend the HC1 back when making the QRCode (which for me is not a correct solution, or maintain the Original QR Code string (version without trimming), and utalize this to save the QRCode in the makeQrCode function.

Current Implementation

No support of iOS 11+

Suggested Enhancement

To support iOS 11, we updated the function “pubKey(from b64EncodedCert: String)” X509.swift like this:

public static func pubKey(from b64EncodedCert: String) -> SecKey? {
      guard let encodedCertData = Data(base64Encoded: b64EncodedCert) else { return nil }
      guard let cert = SecCertificateCreateWithData(nil, encodedCertData as CFData) else { return nil }
      let publicKey: SecKey?
      if #available(iOS 12.0, *) {
        publicKey = SecCertificateCopyKey(cert)
      } else {
        publicKey = SecCertificateCopyPublicKey(cert)
      }
      return publicKey
    }

Expected Benefits

Support of iOS 11+

Once QRs from some countries are scanned then the IOS APP crashes and does not produce any result. EE doesn't use IOS version but other countries that tried had this issue.

Steps to reproduce the issue

1. Go to https://github.com/eu-digital-green-certificates/dgc-testdata/tree/main/EE/png
2. Open the IOS APP
3. Scan one of the QRs

Expected result: Sertificate is valid against Test or Acceptance Test. Actual result: Crash

Technical details

Can't provide any specific technical details or logs. But the suggestion on the call at 5 yesterday was that IOS has problems with some signature calculations/verifications.

Possible Fix

If it is indeed the calculations/verifications then fix the algorithm implementation.

Additional context

Switzerlands QRs were also producing a crash as I was told.

The current SwiftCBOR ignores the tagging of date times (just a support for tag=1 inserted). The swift cbor library should be fixed to accept this QR codes. (https://github.com/PaulBallmann/SwiftCBOR/commit/b76024995f6909e4615f943c7a03268fd29778fc)

See this code here: https://github.com/eu-digital-green-certificates/dgc-testdata/blob/main/SE/png/7.png

Feature description

We're implementing the DGC in TousAntiCovid 🇫🇷

There is UI logic related to the client apps (Verifier et Wallet) that has been centralized in SwiftDGC: there are some pieces of UI, network calls and localization management. Ideally, it would be perfect to only have the pure business logic (parsing + signature check), 100% separated from the client application that will use it.

With that in mind, the changes could help as well to ease the integration of this SDK in apps already on Stores, and make it as light as possible:

• We removed these files from SwiftDGC :

  • Scan.swift
  • UIViewController.swift
  • UITableViewCell.swift
  • UIImage.swift
  • SquareViewFinder.swift
  • AppVersionCell.swift
  • Assets.xcassets
  • ContextConnection.Swift

• We could therefore remove the dependency to Alamofire.

• The HCert model is proposed not to embed anything related to the UI, meaning the info variable that contains localized labels to display.

• It's very useful to have in the SDK the labels to localize everything with a code (for vaccins, tests...). However, the strings used by the UI e.g. "Certificate Type" or "Date of Birth" is already managed on the client app side. That would be useful to have an architecture in which the localization is managed outside the SDK (i.e. managed on the client side). However, that would be helpful to have the SDK managing all codes in all languages (product codes, manufacturers, ...): we would have in one place for all UE countries all the multilingual labels corresponding to the codes.

• In the HCert object, there is a validityFailures array which is containing a list of strings describing the errors. It would be better to have a list of error codes or enum values to be able to map this to description strings on the client app side.

Problem and motivation

The idea is to split this "core", without UI at all.

Is this something you're interested in working on

Yes

Describe the bug

HCert class only exposes a single property .type: HCertType and a single property statement; this is a problem when a certificate contains multiple statements.

For example the pass of a citizen with a test reporting their state as positive could be marked as "valid" because they also have a recovery statement (even if the recovery happened 1 year ago).

Expected behavior

I think all statements should be evaluated, not only the last one, see:

https://github.com/eu-digital-green-certificates/dgca-app-core-ios/blob/53d918f8fac41c40fa494878fdf94810e712b412/Sources/Models/HCert.swift#L305-L319

Since the evaluation order is testStatements + vaccineStatements + recoveryStatements and only the last is used to evaluate the type, a pass holding a recovery and a positive test result (like the example from below) will be marked as valid.

This is a critical behavior of the current version of the iOS app, as the user is currently positive to the test but marked valid.

Steps to reproduce the issue

The following payload describes a person being currently positive (by a test in the last 24 hours) after having recovered from COVID-19 some months ago in April. Since the only statement exposed by the HCert class is the recovery one, the pass will qualify as valid even if the owner is infected.

{
    "ver": "1.2.1",
    "nam": {
        "fn": "Musterfrau-G\u00f6\u00dfinger",
        "gn": "Gabriele",
        "fnt": "MUSTERFRAU<GOESSINGER",
        "gnt": "GABRIELE"
    },
    "dob": "1998-02-26",
   "t": [
        {
            "tg": "840539006",
            "tt": "LP217198-3",
            "ma": "1232",
            "sc": "2021-02-20T12:34:56+00:00", // set to 24h ago
            "tr": "260373001",  // tested positive
            "tc": "Testing center Vienna 1",
            "co": "AT",
            "is": "Ministry of Health, Austria",
            "ci": "URN:UVCI:01:AT:71EE2559DE38C6BF7304FB65A1A451EC#3"
        }
    ],
    "r": [
        {
            "tg": "840539006",
            "fr": "2021-02-20",
            "co": "AT",
            "is": "Ministry of Health, Austria",
            "df": "2021-04-04",
            "du": "2021-10-04",
            "ci": "URN:UVCI:01:AT:858CC18CFCF5965EF82F60E493349AA5#K"
        }
    ]
}

Technical details

• Host Machine OS (Windows/Linux/Mac): iOS

Possible Fix

1. Exposing all statements by marking the existing property as public
2. Removing the statement and type properties as they may be misleading

I think validation of all statements should be left to the app implementing validation (i.e. wallet and verifier).

Additional context

In Scan.swift file, processClassification method, this line of code [.Aztec, .QR, .DataMatrix] is crashing.

as per iOS Document,

@available(macOS, introduced: 10.13, deprecated: 12.0, renamed: "aztec")
@available(iOS, introduced: 11.0, deprecated: 15.0, renamed: "aztec")
@available(tvOS, introduced: 11.0, deprecated: 15.0, renamed: "aztec")
public static let Aztec: VNBarcodeSymbology

It needs to be modified to as renamed names to avoid

[.aztec, .qr, .dataMatrix]

Page 5 of verifiable vaccination certificates - basic interoperability elements states:

A trust framework, including digital infrastructure, that is needed for establishing the authenticity and validity of certificates presented by certificate holders.

Page 11 of Interoperability of health certificates Trust framework states :

3.1.1.7 Health certificate revocation list (HCRL) A system used by Country A for publishing information about revoked health certificates.
Each Country A shall publish one and only one aggregate list of all revoked health certificates. Country A is responsible for putting its revoked certificates on the list and signing it using one of its signing keys controlled by the PHA.

I do not see any implementation of a revocation check.

https://github.com/ehn-digital-green-development/ValidationCore/blob/main/Sources/ValidationCore/Trustlist.swift#L81

Use OIDs with "0" and and without.

Problem

The CWT RFC allows to tag the COSE Objects with a CWT Tag (61) which leads in the current implementation to a n rejection of the QR Code.

Proposed solution

The object should be checked for tag 61, if available the cose message should processed, otherwise the normal cose message is processed directly.

This can be solved maybe by a decoder decorator: https://github.com/SchulzeStTSI/dgca-app-core-ios/tree/fix/tag-61

The COSE-JAVA can handle this, maybe the fix has to be done in the SWIFT-CBOR library.

This pull request should solve the tag type problem and provides validation unit tests/QR codes for testing. Some functions were removed, please evaluate if this was too enthusiastic.

@yspreen comments welcome

Describe the bug

When trying to run a fresh clone of the verifier, I sometimes get random crashes on the https://github.com/eu-digital-green-certificates/dgca-app-core-ios/blob/main/Sources/Services/ContextConnection.swift#L37 at the alamofireSession creation and sometimes it passes that point and gets stuck on the splash screen. On the iOS 14.x it works as expected.

#       alamofireSessions[url] = Alamofire.Session(serverTrustManager: trust)
Thread 6: EXC_BAD_ACCESS (code=1, address=0x10)

#     let session = alamofireSessions[url] ?? AF
Thread 8: "-[__NSCFNumber count]: unrecognized selector sent to instance 0x8000000000000000"

Expected behaviour

For the Verifier to work

Steps to reproduce the issue

1. Clone dgca-app-core-ios, dgc-certlogic-ios, dgca-verifier-app-ios
2. Run dgca-verifier-app-ios
3. Re-run dgca-verifier-app-ios

Technical details

• MacOS: 11.6
• XCode: 13.1
• Device: iPhone 8 - iOS 15.0

Possible Fix

This could be helpful https://github.com/Alamofire/Alamofire/issues/3122

Hello,

• Source File: X509.swift
• Line(s): 125 - 152
• Question: Is it normal that when we scan a DCC vaccine or other function isType returns false when normally (if I understood the code) we should with the isType to true to then pass in the switch to verify that we had the right OID for the right type of certificate ?

I can give you a DCC vaccin or other type to check that we are going through the 'return true' of line 139 and not through the switch which seems strange to me.

Regards

Your Question

Hi, I've noticed that this project uses the SwiftyJSON library. While it's really valid and I've used it myself in the past, it's still a dependency and adds a level of overhead for json decoding. Is there a reason why this was chosen over the Codable decoding offered natively by Apple?

If there's no particular reason to use SwiftyJSON, I could make a PR and try to implement the json decoding with codable.

Describe the bug

We can't parse the "sc" date field of the Test entity which has the value "2021-07-14T15:10:00+02" and the phone date display is in 12-hour format.

{
    "ver": "1.2.1",
    "nam": {
        "fn": "DUPONT",
        "gn": "Jonathan",
        "fnt": "DUPONT",
        "gnt": "JONATHAN"
    },
    "dob": "1982-06-12",
    "t": [
        {
            "tg": "840539006",
            "tt": "970970",
            "ma": "autotest",
            "sc": "2021-07-14T15:10:00+02",
            "tr": "260415000",
            "tc": "test",
            "co": "FR",
            "is": "CNAM",
            "ci": "URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"
        }
    ]
}

Expected behaviour

The "sc" format is correctly parse else the TestEntry return will be nil.

Technical details

• All platforms

Current Implementation

Decoded JSON fields might contain whitespaces. E.g. GR/EL QR Vaccination Codes in Field "mp"

Suggested Enhancement

During the CBOR Deserialization, all fields must be trimmed for whitespaces.