Difference between revisions of "Wallet Notices"
From MgmtWiki
(→Solutions) |
(→Goals) |
||
| (26 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title== | ==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 contents and availability of notification to the user of a digital [[Wallet]] needs to satisfy both privacy concerns and user preferences. | ||
| + | ==Goals== | ||
| + | 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 authorized to be 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 breaches and any terms updates will be stored by the wallet along with [[Verifier]] requests that the user has accepted. | ||
| + | * The user will be able to view these notifications for as long as the user has told the wallet to retain them. | ||
==Context== | ==Context== | ||
| − | * The term user here applies to wallets holders and [[Subject]]s when they are different from the holder. | + | * The term "user" here applies to wallets holders and [[Subject]]s when they are different from the holder. |
* Typically only the holder (owner) of the wallet receives and stores notices. | * Typically only the holder (owner) of the wallet receives and stores notices. | ||
| − | * This | + | * 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. | * 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. |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Problems== | ==Problems== | ||
| − | * User fatigue sets in on excessive notice displays. This fatigue is different for different | + | * 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. |
| − | * [[Smartphone]]s typically have one overall notification setting per app. The wallet setting should be on, but | + | * [[Smartphone]]s typically have one overall notification setting per app. The wallet notification setting should be on, but many users may not choose to enable it. |
| − | ** The wallet may require notifications before they start operations, but marketing staff are likely to object to that requirement. | + | ** 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 | + | * Some wallet devices can be tracked by the radio signals that are released as a part of establishing a connection 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. | * 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. | ||
==Solutions== | ==Solutions== | ||
| − | * The initial message from the [[Verifier]] to the user must contain: | + | * The initial message from the [[Verifier]] to the user must contain: (Note the modifier "initial" as this does not apply to later connections.) |
# An identification of the [[Verifier]] that can be presented to the user in terms that they can understand. | # 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. | # 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. | ||
| − | * | + | ## The purpose(s) for which the user credential and other data is required. This must be something the user sees and understands. |
| − | + | ## If the purpose is not sufficient the wallet can present detailed data requests so long as they are covered by the purpose. | |
| + | ## Optionally the verifier can ask for data this is not required, but this requires opt-in by the user. | ||
| + | ## Some indication as to the 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. | ||
| + | * The [[User Experience]] must allow the holder to review past transactions with any site that asks for subject private information. | ||
===Audit=== | ===Audit=== | ||
* The only way to verify that privacy-preserving mandates are satisfied is for some level of auditing as to what a [[Verifier]] actually does. | * The only way to verify that privacy-preserving mandates are satisfied is for some level of auditing as to what a [[Verifier]] actually does. | ||
Latest revision as of 09:18, 5 February 2024
Full Title
The contents and availability of notification to the user of a digital Wallet needs to satisfy both privacy concerns and user preferences.
Goals
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 authorized to be 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 breaches and any terms updates will be stored by the wallet along with Verifier requests that the user has accepted.
- The user will be able to view these notifications for as long as the user has told the wallet to retain them.
Context
- 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.
Problems
- 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 users may not choose 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 establishing a connection 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.
Solutions
- The initial message from the Verifier to the user must contain: (Note the modifier "initial" as this does not apply to later connections.)
- 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.
- The purpose(s) for which the user credential and other data is required. This must be something the user sees and understands.
- If the purpose is not sufficient the wallet can present detailed data requests so long as they are covered by the purpose.
- Optionally the verifier can ask for data this is not required, but this requires opt-in by the user.
- Some indication as to the 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.
- The User Experience must allow the holder to review past transactions with any site that asks for subject private information.
Audit
- 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.
References
- See wiki page on Wallet User Experience
- See wiki page on Self-issued ID chooser UX
- See wiki page on Wallet
