Feature description

I think there should be an option to integrate certificates, passes and other cards directly in Apple Wallet, so this documents could be accessed in one central App and the same place where are already stored things like creditcards from Apple Pay, loyaltycards and tickets.

https://developer.apple.com/wallet/

So there could be displayed an „Add to Apple Wallet“ button in the details of each document, so the user can decide which of them should be added to the iOS-native Wallet-App.

I‘m not sure, if passes in the Wallet-App are stored in the Secure Enclave, but if this isn’t the case, this feature maybe could be at least provided for „simpler“ documents, like vaccination certificates.

Problem and motivation

I really think, it is a very important feature for iOS-Users to create a functionality to use the native Wallet-App for documents like these. And iOS-Users are more often looking towards such an integration, as they really like the simplicity and convenience of things like the native Wallet-App especially if they are already using stuff like Apple Pay.

This would provide a much better experience for the users and this could also help to convince more users from using digital certificates.

As I couldn’t find any information regarding this Apple Wallet topic, I’ve created this feature-request.

Is this something you're interested in working on

No.

Describe the bug

on starting the App on my iphone, there is no secure request to enter the app if no biometric or alternate secure is saved on mobile device.

Expected behaviour

On starting the App there have to be a login mechanism with biometric data or pin or template. If there are no biometric data saved on mobile device, the user has to save one secure login possibility. Otherwise a start of the app is not possible.

Steps to reproduce the issue

1. restart the iphone to be sure no app is running anymore
2. open the walletApp
3. no login is requested

Technical details

IPhone Xs IOS-version: 14.4. (18D52)

Possible Fix

Additional context

If a revoked cerificate expires while it is stored in the wallet, then this is shown as revoked after the expiration date too although the reload button is pressed.

Expected behaviour: Certificates should be shown as valid after reloading the settings menu and refreshing the overview screen.

Revoked certificates are not always shown as revoked on some devices as expected. This problem could mostly be resolved with the workaround by scrolling or by reload. But it does not guarantee that it would work.

Expected behaviour

At least in the list view after scrolling or reloading multiple times there should be some indication of revoked certificates.

Steps to reproduce

1. Claim the following certificate (which is revoked); The current TAN for claiming this certificate is: M36Z2V7D
2. Press reload in app settings;
3. Scroll up and down the certificate list. => no indication of "revoked" is to be seen.

Technical Details

iOS Wallet App 1.3.1 (5) tst iPhone 8 plus v. Lutz, iOS 15.3.1

iOS wallet app 1.2.2.1 (3) acc iPad 11 Pro

expected result There should be an OK oe Close button to go back to the main screen of the wallet app

actual result confirmation screens stays open and I had to kill the app

sample from Android:

Describe the bug

on choosing a certificate to check the validity, the choosen country has no rules. Even if I know that the country should have rules.

Expected behaviour

the choosen certificate should be checked by choosen date and country.

Steps to reproduce the issue

1. Open WalletApp
2. choose a already saved certificate
3. push the button: "check Validity"
4. choose a country with businessRules
5. Choose a date
6. push "I Agree, check validity
7. see the message: "Sorry! no rules for this country"

Technical details

• Host Machine OS (Windows/Linux/Mac): IPhone Xs Modellnummer: MT9G2ZD/A IOS-Version: 14.6 (18F72) ENF-Version: WalletApp Version 1.1.0

Possible Fix

Additional context

Describe the bug

We tried to can a Verifiable Credential Code with Null-values. The app could not read the code. It was not scannable. (See attached code).

Expected behaviour

The app should be able to scan such codes.

Technical details

iOS Wallet App 1.3.3(4)

When certificate is already claimed to wallet app and will be revoked later, the revokation status is not updated.

1. Claim valid certificate
2. Revoke certificate
3. Wait about 10 minutes
4. Update revokation status in settings menu
5. Scroll down certificate list

Expected result: certificate should be shown as revoked

Actual result: certificate is shown as valid

6. Claim the certificate again to app -> certificate is shown as revoked

Describe the bug

when i want to share a non-DCC PDF, there is no "Share"-Button visible

Expected behaviour

a non-DCC PDF is saved. when the pdf is viewd in walletApp, the must be a "Share"-Button to share the pdf

Steps to reproduce the issue

1. save non-dcc in walletApp
2. open the saved pdf

Technical details

iPhone 7, IOS 15.3.1 WalletApp 1.3.1 (5) testform1.pdf

Hi all, big thanks to all for making this project open-source.

Slovakia e.g. declares to have functionality that allows wallet app to share/display QR codes with 'anonymized' data (my guess is that the QR e.g. does not contain a person's name or date of birth).

I am interested only in the technical point of view of this question - so do you know about ways how this could be accomplished, please?

I checked the default JSON schema, where "nam" (person's surname and given name) and "dob" are required.

So I think the only way, how this could be accomplished, is that issuer would always issue 2 kinds/2 versions of certificates for a single test, single vaccination, or single recovery "event":

-one anonymized where the personal data fields would be just placeholders / containing dummy values to pass JSONSchema validation step -and the second, with original personal data

I see no point, in a solution where the wallet removes personal data (like 'tampering certificate'), as the signature for the verifier would become invalid.

Could you suggest other ideas (if any) / or tell me if I am wrong somewhere with the solution above, please?

I am not a representative, nor a member of any official working group - so I do not want to waste the time of any of you if you are currently under pressure.

Thanks.

Your Question

in User Story 2: Import Green Certificate in the Wallet App, is a second optionally way to import the cerificate by a deep link which was sended by SMS or email.

Optionally you can use a deep link instead of a 2D Code to initiate the certificate import in the wallet app. The deep link can look like: dgc://example.authority.com?token=ey… & [publickey] In this case the token is received with the link, and the public key must be replaced by the key of the new generated key pair of the certificate container in the wallet app. The deep link can be delivered by SMS, Email or by presenting another 2D Code for scan.

You find it in specification: https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-certificates_v4_en.pdf on page 12

• Question: When will it be implemented?

Functional the loading of data seems to work (country list ist loaded, and revokation data is updated) but visuell the reloading date of keys and revokation data is not changed, always stay on 0001-01-01

The new wallet 1.3.3(11) has an entry "Grund der Invalidität" "Keine Einträge im Zertifikat" but this should be not part of the wallet app.

Here is the example for the same certifikat in wallet Android without this entry:

Describe the bug

A verifiable credential (see attached file) with matching KID but wrong public key data could be saved in the wallet app despite the wrong public key data (invalid signature).

Expected behaviour

The app should recognize the invalidity of the signature and deny saving the credential due to invalid signature.

Technical details

Wallet App Hash 1.3.3(4)

The problem is that when one certificate is claimed more than one time, only the last claimed become to the prior certificate. Means that only for this newest claimed the public keys are can be found in the gateway. So for the older claimed (on other devices or on the same device) the revokation reload function fails with 400 in the API.

Possible solution should be to ask for the information from the gateway for every single one certificate and not only to get answer for the whole set of certificates.

@SchulzeStTSI maybe you can explain possible solution here in detail.

This removes the FloatingPanel dependency because:

• FloatingPanel was only used to present Viewcontroller modally which is supported by System APIs just fine
• Animation feels more natural when using System API
• Less Code to reason about
• Less Licensing
• Less risk of bugs & sec vulnerabilities
• Smaller binary size

Feel free to reject this PullRequest if there are good reasons to use FloatingPanel.