Difference between revisions of "Wallet Notices"

Revision as of 17:59, 4 February 2024

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. This is established by the Architectural Framework.

The whole point of Wallet Notices is to supply the data needed for a stress-free User Experience with credentials and other private data.
Either the user has selected the wallet to contact the Verifier, or the initial request from the Verifier is used by the device to direct the request to the Wallet.
Notices from the Verifier identify it and the verified data it needs for the purpose of providing access to some resource.
The display of the Verifier notification will be created by the Wallet based on user settings.
Some sort of user gesture is to be required by the Wallet before any data about the user or wallet is sent to the Verifier.
Once user data has been release to the Verifier it is responsible for notifications of any release of user data not approved by the user.
When possible these breach or terms updates will be stored by the wallet along with the requests that the user has accepted.
The user will be able to view these notifications for as long is the user has asked the wallet to retain them.

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.
1. The purpose(s) fro which the user credential and other data is required. This must be something the user sees and understands.
2. If the purpose is not sufficient the wallet can present detailed data requests so long as they are covered by the purpose.
3. Optionally the verifier can ask for data this is not required, but this requires opt-in by the user.
4. Some indication as the to retention period for data if it is stored by the Verifier beyond the verification process itself.
5. Whenever data is stored, some contact information must be supplied for the user to determine what data is stored or request deletion of the data.
6. The jurisdiction under which the data retention is controlled. (Whether this is part of trust registry is tbd.)

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.

@@ Line 36: / Line 36: @@
 ## Some indication as the to retention period for data if it is stored by the [[Verifier]] beyond the verification process itself.
 ## Whenever data is stored, some contact information must be supplied for the user to determine what data is stored or request deletion of the data.
+## The jurisdiction under which the data retention is controlled. (Whether this is part of trust registry is tbd.)
 * 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.