Wallet Notices

Full Title

The contents and availability of notification to the user of a digital Wallet needs to satisfy both privacy concerns and user preferences.

The following are the required success criteria for both the user and the Verifier.

The identification of the Verifier must be established prior to the release of any information that can be used to identify or track the user.
Once an enduring relationship has been established with a user as evidenced by the acquisition of user information, the Verifier is obligated to notify the user by some channel when that information is released under any condition not approved by the user.

The term user here applies to wallets holders and Subjects when they are different from the holder.
Typically only the holder (owner) of the wallet receives and stores notices.
This document considers only the role of the Verifier as it is assumed that the issuer or any other party first needs to verify the wallet and holder of the wallet before exchanging any certificate data.
Government legislation that mandates the release of information on different terms than these is not in the scope of this page.
A Privacy Transparency Statement will be included in (or prior to) any request for Subject information.

User fatigue sets in on excessive notice displays. This fatigue is different for different users and so display thresholds need to be under user control.
Smartphones typically have one overall notification setting per app. The wallet notification setting should be on, but many user may not chose to enable it.
- The wallet may require notifications before they start operations, but product marketing staff are likely to object to that requirement.
- Smartphones provide detailed settings under notifications (Banners, Sounds, Badges, etc.), but they are very seldom part of the user's attention.
Some wallet devices can be tracked by the radio signals that are released as a part of establish a connecting to the wallet.
At the time that the Verifier creates the request and provides their own Identifier and privacy transparency statement, the Identifier of the Holder is not known. The Verifier probably records the endpoint network address of the Entity that contacted them, but that could just be the address of a VPN endpoint.
Most statements of terms and conditions are too long for display on a single wallet screen to the user, but still must be available in some form that persists in the wallet and can be examined by the user whenever they wish to view them.

An identification of the Verifier that can be presented to the user in terms that they can understand.
A Privacy Transparency Statement that can be presented to the user as a part of a request to which the user must positively indicate acceptance.

On any extended relationship between the verifier and holder, changes to future transaction terms and conditions must create a new consent request.
Breach notifications are likely to be covered by local government regulations. Where possible these should be as notifications to the wallet.
The User Experience must allow the holder to review past transactions with any site that asks for subject private information.

The only way to verify that privacy-preserving mandates are satisfied is for some level of auditing as to what a Verifier actually does.
Audits are likely to have some information that should not be released to the public.
A list of notifications from Verifiers should be maintained by user wallets for the user's sole benefit. This can be considered to be an audit trail.
Audit trails in the Verifier containing user private information must be protected by encryption or similar levels of disclosure protection.

The following information summarizes notifications from the point of a Architecture Overview and could be included in such a document.