|
RP Access Certificate verification failure in issuance flow
|
Block issuance when RP access certificate verification fails
|
|
6 |
Given an issuance flow has been initiated by a Relying Party
When the Wallet processes the RP Access Certificate
And the certificate verification fails
Then the Wallet terminates the issuance interaction
And the Wallet displays a notification informs the Wallet user that the issuance has been blocked indicating that the RP could not be verified
And the Wallet displays a clear notification to the Wallet user that no information about the Wallet user has been shared
|
FAILURE
|
|
RP Access Certificate verification failure in presentation flow
|
Block presentation when RP access certificate verification fails
|
|
5 |
Given a presentation flow has been initiated by a Relying Party
When the Wallet processes the RP Access Certificate
And the certificate verification fails
Then the Wallet terminates the presentation interaction
And the Wallet displays a clear notification to the Wallet user that no information about the Wallet user has been shared
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
User initiates verification from Desktop browser
|
|
3 |
Given the user is on the Relying Party service page
When the user initiates the wallet verification flow
Then a presentation request flow is initiated
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
Desktop browser requests permission for Digital Credentials API
|
|
3 |
Given a presentation request flow has been initiated
When the Desktop browser invokes the Digital Credentials API
Then the user is prompted to grant permission
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
User grants permission on Desktop browser
|
|
3 |
Given the browser displays a permission prompt
When the user grants permission
Then the Relying Party generates a valid presentation request
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
QR code is displayed for cross-device flow
|
|
3 |
Given a valid presentation request has been created
When the browser processes the request
Then a QR code is displayed to the user
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
User scans QR code using mobile device
|
|
3 |
Given a QR code is displayed on the Desktop browser
When the user scans the QR code with the mobile device camera
Then the presentation request is transferred to the mobile device
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
Mobile OS searches for matching attestations
|
|
3 |
Given the mobile device has received a presentation request
When the Mobile Operating System evaluates installed Wallet Units
Then suitable attestations matching the request are identified
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
No matching attestations on mobile device
|
|
3 |
Given the mobile device has received a presentation request
When no installed Wallet Unit contains suitable attestations
Then the user is notified and the process is terminated
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
Mobile OS displays selector with matching attestations
|
|
3 |
Given suitable attestations exist on the mobile device
When the Mobile Operating System prepares the selection interface
Then a list of matching attestations is displayed
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
Attestation identifying information is displayed
|
|
3 |
Given the selector interface is displayed
When the user views the list of attestations
Then each attestation displays credential type, and wallet name
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
Selector indicates Wallet Unit ownership
|
|
3 |
Given multiple Wallet Units contain suitable attestations
When the selector interface is shown
Then each attestation indicates the Wallet Unit that holds it
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
User selects an attestation and Wallet opens
|
|
3 |
Given the selector interface displays matching attestations
When the user selects one attestation
Then the corresponding Wallet Unit is invoked
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
Wallet displays requested attestations and attributes
|
|
3 |
Given the Wallet has verified the Relying Party
When the presentation request screen is shown
Then the requested attestations and related attributes are displayed
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
Successful consent and authentication
|
|
3 |
Given the presentation request screen is displayed in the Wallet
When the user consents to share attributes and enters a valid six-digit PIN
Then the attestation is presented successfully
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
Relying Party verifies attestation successfully
|
|
3 |
Given the attestation has been presented from the mobile Wallet
When the Relying Party validates the attestation successfully
Then a verification confirmation is displayed in the Desktop browser
|
SUCCESS
|
|
Cross-Device Presentation of Digital Attestations via EUDI Wallet
|
Relying Party verification fails
|
|
3 |
Given the attestation has been presented from the mobile Wallet
When the Relying Party fails to validate the attestation
Then an error message is displayed and retry is allowed
|
SUCCESS
|
|
Present Digital Attestations via Browser using EUDI Wallet on Same Device
|
User initiates verification from browser
|
|
3 |
Given the user is on the Relying Party service page
When the user initiates the wallet verification flow
Then a presentation request is initiated by the Relying Party
|
SUCCESS
|
|
Present Digital Attestations via Browser using EUDI Wallet on Same Device
|
Browser requests permission for Digital Credentials API
|
|
3 |
Given a presentation request has been initiated
When the browser processes the Digital Credentials API invocation
Then the user is prompted to grant permission
|
SUCCESS
|
|
Present Digital Attestations via Browser using EUDI Wallet on Same Device
|
User grants Digital Credentials API permission
|
|
3 |
Given the browser displays a permission prompt
When the user grants permission
Then the Operating System starts searching for suitable attestations
|
SUCCESS
|
|
Present Digital Attestations via Browser using EUDI Wallet on Same Device
|
Matching attestations are found on the device
|
|
3 |
Given the Operating System searches installed Wallet Units
When suitable attestations matching the request exist
Then the browser displays a selector interface with the matching attestations
|
SUCCESS
|
|
Present Digital Attestations via Browser using EUDI Wallet on Same Device
|
No matching attestations found
|
|
3 |
Given the Operating System searches installed Wallet Units
When no suitable attestations match the request
Then the user is notified and the process is terminated
|
SUCCESS
|
|
Present Digital Attestations via Browser using EUDI Wallet on Same Device
|
Attestation details are displayed in selector
|
|
3 |
Given matching attestations are displayed in the selector interface
When the user views the attestation list
Then each attestation displays credential type, and wallet name
|
SUCCESS
|
|
Present Digital Attestations via Browser using EUDI Wallet on Same Device
|
Selector indicates Wallet Unit ownership
|
|
3 |
Given multiple Wallet Units contain suitable attestations
When the selector interface is displayed
Then each attestation indicates which Wallet Unit holds it
|
SUCCESS
|
|
Present Digital Attestations via Browser using EUDI Wallet on Same Device
|
User selects an attestation and Wallet opens
|
|
3 |
Given the selector interface displays suitable attestations
When the user selects one attestation
Then the corresponding Wallet Unit is automatically invoked
|
SUCCESS
|
|
Present Digital Attestations via Browser using EUDI Wallet on Same Device
|
Wallet verifies Relying Party identity and origin
|
|
3 |
Given the Wallet Unit is opened after attestation selection
When the presentation request screen is shown
Then the requested attestations and related attributes are displayed
|
SUCCESS
|
|
Present Digital Attestations via Browser using EUDI Wallet on Same Device
|
User consents and proceeds to authentication
|
|
3 |
Given the presentation request screen is displayed in the Wallet
When the user provides consent to share selected attributes
Then the Wallet requests PIN authentication
|
SUCCESS
|
|
Present Digital Attestations via Browser using EUDI Wallet on Same Device
|
Successful authentication and presentation
|
|
3 |
Given the Wallet requests PIN authentication
When the user enters a valid six-digit PIN
Then the attestation is presented successfully
|
SUCCESS
|
|
Present Digital Attestations via Browser using EUDI Wallet on Same Device
|
Relying Party verifies attestation successfully
|
|
3 |
Given the attestation has been presented to the Relying Party
When the Relying Party validates the attestation successfully
Then a verification confirmation is displayed in the browser
|
SUCCESS
|
|
Present Digital Attestations via Browser using EUDI Wallet on Same Device
|
Relying Party verification fails
|
|
3 |
Given the attestation has been presented to the Relying Party
When the Relying Party fails to validate the attestation
Then an error message is displayed and retry is allowed
|
SUCCESS
|
|
One-time-use attestation issuance under Method A (once_only)
|
User sees a normal credential after issuance
|
|
3 |
Given the issuer has issued a new batch of one time use credentials to my wallet
When I open my wallet
Then I see the credential displayed like any other credential
|
SUCCESS
|
|
One-time-use attestation issuance under Method A (once_only)
|
User can present the credential without noticing special behavior
|
|
3 |
Given I hold a one time use credential with four of four uses remaining
When I present the credential to a verifier
Then the presentation completes successfully with no unusual prompts or steps
|
SUCCESS
|
|
One-time-use attestation issuance under Method A (once_only)
|
Counter is shown after issuance
|
|
3 |
Given the issuer has issued a new batch of four one time use credential instances
When I view the credential in my wallet
Then I see a counter showing four of four remaining
|
SUCCESS
|
|
One-time-use attestation issuance under Method A (once_only)
|
Counter decreases after a successful presentation
|
|
3 |
Given I hold a one time use credential with four of four uses remaining
When I successfully present the credential to a verifier
Then I see the counter update to three of four remaining
|
SUCCESS
|
|
One-time-use attestation issuance under Method A (once_only)
|
Warning indicator appears when only one use is left
|
|
3 |
Given I hold a one time use credential with one of four uses remaining
When I view the credential in my wallet
Then I see an orange warning indicator with an accompanying icon
|
SUCCESS
|
|
One-time-use attestation issuance under Method A (once_only)
|
User is not prompted to act when the warning appears
|
|
3 |
Given I hold a one time use credential with one of four uses remaining and the warning indicator is displayed
When I view the credential in my wallet
Then I am not asked to take any action
|
SUCCESS
|
|
One-time-use attestation issuance under Method A (once_only)
|
Counter resets to full after reissuance completes
|
|
3 |
Given the wallet has silently reissued a fresh batch of credentials to replace the depleted batch
When I next open my wallet
Then I see the counter showing four of four remaining
|
SUCCESS
|
|
Reusable attestation with silent renewal under Method B (limited_time)
|
User sees a normal credential after issuance
|
|
4 |
Given the issuer has issued a credential under Method B
When I open my wallet
Then I see a single credential instance displayed like any other credential
And the credential has a batch size of one
|
SUCCESS
|
|
Reusable attestation with silent renewal under Method B (limited_time)
|
User can present the credential repeatedly without noticing time-based behavior
|
|
3 |
Given I hold a valid credential issued under Method B
When I present the credential to a verifier multiple times
Then each presentation completes successfully without decreasing the counter of the instances
|
SUCCESS
|
|
Reusable attestation with silent renewal under Method B (limited_time)
|
No timers or countdowns are shown to the user
|
|
3 |
Given I hold a valid credential issued under Method B
When I view the credential in my wallet
Then I do not see any timer, countdown, or expiration warning
|
SUCCESS
|
|
Reusable attestation with silent renewal under Method B (limited_time)
|
Wallet silently refreshes the credential when it nears expiry
|
|
3 |
Given I hold a credential whose remaining lifetime has fallen below the reissue trigger lifetime left threshold
When the wallet checks the credential's remaining lifetime
Then the wallet silently reissues a fresh credential instance without notifying me
|
SUCCESS
|
|
Randomized balanced rotation with silent renewal under Method C (rotating-batch)
|
Credential always displays full availability
|
|
3 |
Given the issuer has issued a batch of N credential instances under Method C
When I view the credential in my wallet
Then I see the counter showing N of N
|
SUCCESS
|
|
Randomized balanced rotation with silent renewal under Method C (rotating-batch)
|
Counter never shows deletion or decreasing values
|
|
3 |
Given I hold a credential backed by a batch of N instances under Method C
When I present the credential repeatedly
Then the counter continues to display N of N and never decreases
|
SUCCESS
|
|
Randomized balanced rotation with silent renewal under Method C (rotating-batch)
|
Wallet silently refreshes the batch when its lifetime is close to ending
|
|
3 |
Given the batch's remaining lifetime has fallen below the reissue trigger lifetime left threshold provided by the issuer
When the wallet checks the batch's remaining lifetime
Then the wallet silently reissues a fresh batch of N instances without notifying me
|
SUCCESS
|
|
Randomized balanced rotation with silent renewal under Method C (rotating-batch)
|
Credential shows full availability after silent renewal
|
|
3 |
Given the wallet has silently reissued a fresh batch to replace the near expiry batch
When I next open my wallet
Then I see the counter showing N of N
|
SUCCESS
|
|
Wallet Interprets Credential Reuse Policy Metadata
|
User sees a normal credential-issuance flow
|
|
3 |
Given the issuer metadata includes a credential reuse policy with at least one supported option
When I proceed through credential issuance
Then I see a normal issuance flow with no additional steps related to reuse behavior
|
SUCCESS
|
|
Wallet Interprets Credential Reuse Policy Metadata
|
User is not asked to choose a reuse behavior
|
|
3 |
Given the issuer metadata includes a credential reuse policy with multiple supported options
When I proceed through credential issuance
Then I am not prompted to select a reuse method
|
SUCCESS
|
|
Wallet Interprets Credential Reuse Policy Metadata
|
Wallet automatically applies the issuer's preferred behavior
|
|
3 |
Given the issuer metadata includes a credential reuse policy with a single option that the wallet supports
When the wallet processes the issuer metadata
Then the wallet silently applies that reuse method to the issued credential
|
SUCCESS
|
|
Wallet Interprets Credential Reuse Policy Metadata
|
Wallet silently selects the first fully supported policy when multiple options exist
|
|
3 |
Given the issuer metadata includes a credential reuse policy listing multiple options in order of preference
When the wallet processes the issuer metadata
Then the wallet silently selects and applies the first option it fully supports
|
SUCCESS
|
|
Wallet Interprets Credential Reuse Policy Metadata
|
Wallet falls back to its own default reuse policy in case of no rule
|
|
3 |
Given the issuer metadata does not include a credential reuse policy
When the wallet processes the issuer metadata
Then the wallet does not show an error and it falls back to its own default reuse policy
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
Display all valid combinations
|
|
3 |
Given the user opens the RP request
When the Wallet loads the request
Then it displays all valid credential combinations that satisfy the request
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
Display only valid combinations
|
|
3 |
Given the Wallet contains stored credentials
When the Wallet evaluates possible combinations
Then it displays only valid combinations based on the stored credentials
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
User must select one combination when multiple exist
|
|
3 |
Given more than one valid credential combination exists
When the Wallet displays the combinations
Then the user must select exactly one before continuing
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
Each option shows which credentials will be shared
|
|
3 |
Given the Wallet displays available combinations
When the user views the options
Then each option clearly indicates which credentials will be shared
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
Only one valid combination exists
|
|
3 |
Given only one valid credential combination exists
When the Wallet displays it
Then the user can proceed without making a selection
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
No valid combinations available
|
|
3 |
Given the Wallet does not contain the required credentials
When the Wallet evaluates the request
Then it displays an error message explaining the request cannot be fulfilled
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
Show information that will be shared
|
|
3 |
Given the user has selected a valid combination
When the user proceeds
Then the Wallet shows exactly which information will be shared with the RP
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
Do not show or share unrequested information
|
|
3 |
Given the user proceeds with a valid combination
When the Wallet prepares the data
Then it does not show or share any information not requested by the RP
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
Canceling the flow
|
|
3 |
Given the user is in the sharing flow
When the user cancels
Then the Wallet returns to the previous screen without sharing any information
|
SUCCESS
|
|
Improve Add Document Flow UI
|
Instances count is not displayed during issuance
|
|
3 |
Given the user is at the Add Document screen
When user attempts to issue an attestation
Then The instances count is not displayed during issuance
|
SUCCESS
|
|
Improve Add Document Flow UI
|
Verify QR button presence
|
|
3 |
Given the user navigates to the Add Document screen
When the user selects from List option
Then a QR button should be visible in the upper right corner
|
SUCCESS
|
|
Improve Authentication Flow UI
|
Verify navigation to Authentication Intro screen
|
|
3 |
Given the user is on the Home page and selects Authenticate
When the user selects either in person or online
Then the title Authenticate my identity is displayed
|
SUCCESS
|
|
Improve Authentication Flow UI
|
Verify informative text
|
|
3 |
Given the user is on the Home page and selects Authenticate
When the user selects online
Then the informative text Scan a QR code provided from an interacting party to authenticate your identity is displayed
|
SUCCESS
|
|
User document management experience
|
Verify + button is removed in Android
|
|
3 |
Given the user launches the app on Android
When the Document List screen is displayed
Then the + button is not visible
|
SUCCESS
|
|
User document management experience
|
Verify search field label
|
|
2 |
Given the user is on the Document List screen
Then the search field should display the label Search
|
SUCCESS
|
|
User document management experience
|
Verify Android FAB behavior on scroll
|
|
5 |
Given the user is on the Document List screen on Android
When the user scrolls down the list
Then the Add document FAB should collapse to icon only
When the user scrolls up
Then the FAB should expand to show label and icon
|
SUCCESS
|
|
User document management experience
|
Remaining instances section
|
|
3 |
Given the user opens a document details screen
When the user navigates at the bottom of the screen
Then the remaining instances section is displayed at the bottom of the screen
|
SUCCESS
|
|
User document management experience
|
Verify Eye button placement and text
|
|
2 |
Given the user is on the Document Details screen
Then the Eye button should be placed next to Document Details text
|
SUCCESS
|
|
User document management experience
|
The Issuer details card is displayed on top
|
|
3 |
Given the user is on the Document Details screen
When the user observes the top of the screen
Then the Issuer details card is displayed on top
|
SUCCESS
|
|
User document management experience
|
Verify rename of delete button in Android
|
|
3 |
Given the user is on the Document Details screen on Android
Then the button should be labeled Remove from wallet
And the text Delete document should not be visible
|
SUCCESS
|
|
User document management experience
|
Verify arrow direction when collapsed
|
|
3 |
Given the user opens the Filter screen on Android
And a filter section is collapsed
Then the arrow icon should point down
|
SUCCESS
|
|
User document management experience
|
Verify arrow direction when expanded
|
|
3 |
Given the user opens the Filter screen on Android
When the user expands a filter section
Then the arrow icon should point up
|
SUCCESS
|
|
Improve History Flow UI
|
Verify Transactions label is updated
|
|
3 |
Given the user navigates through the application
Then all instances of Transactions should be renamed to History
And the corresponding icon should be updated
|
SUCCESS
|
|
Improve History Flow UI
|
Verify search field label
|
|
2 |
Given the user is on the History screen
Then the search field should display the label Search
|
SUCCESS
|
|
Improve History Flow UI
|
Verify arrow direction when collapsed on Android
|
|
3 |
Given the user opens the Filter screen on Android
And a filter section is collapsed
Then the arrow icon should point down
|
SUCCESS
|
|
Improve History Flow UI
|
Verify arrow direction when expanded on Android
|
|
3 |
Given the user opens the Filter screen on Android
When the user expands a filter section
Then the arrow icon should point up
|
SUCCESS
|
|
Improve My Wallet Flow UI
|
Verify Change PIN screen title
|
|
3 |
Given the user navigates to the Settings Option button
When the user navigates to the Change PIN screen
Then the screen title is displayed as Change PIN
|
SUCCESS
|
|
Improve My Wallet Flow UI
|
Verify prompt appears when tapping Back
|
|
3 |
Given the user is on the Change PIN screen
When the user taps the Back button
Then An informational prompt appears with the text: Cancel PIN change?
|
SUCCESS
|
|
User onboarding experience
|
Logo consistency across onboarding
|
|
3 |
Given the user opens the app either for the first time, or for next time
When the user navigates through onboarding screens
Then the updated logo is displayed on all screens
|
SUCCESS
|
|
User onboarding experience
|
Type PIN screen informational text
|
|
3 |
Given the user opens the app for the first time
When the user navigates to the Welcome to your wallet screen
Then the following text is displayed: Secure your wallet with a PIN code and connect to your National System below the Welcome to your Wallet
|
SUCCESS
|
|
User onboarding experience
|
Type PIN screen label
|
|
3 |
Given the user opens the app for the first time
When the user navigates to the Welcome to your wallet screen
Then the Label Type a PIN is displayed above the PIN input fields
|
SUCCESS
|
|
User onboarding experience
|
Type PIN screen "Next" button removal
|
|
3 |
Given the user opens the app for the first time
When the user navigates to the Welcome to your wallet screen and types a PIN
Then the Next button is removed
|
SUCCESS
|
|
User onboarding experience
|
Confirm PIN screen informational text
|
|
4 |
Given the user types a PIN for a first time
When confirm PIN screen is displayed
Then this text is displayed Secure your wallet with a PIN code and connect to your National System
And Label Confirm PIN is displayed above the input fields
|
SUCCESS
|
|
User onboarding experience
|
Confirm PIN screen Confirm button removal
|
|
3 |
Given the user types a PIN for a first time
When confirm PIN screen is displayed
Then the Confirm button is removed
|
SUCCESS
|
|
User onboarding experience
|
Home tab greeting updated
|
|
3 |
Given the user opens the app again after issuing a PID
When user navigates to the Home tab
Then the greeting is updated to Welcome, [Name]
|
SUCCESS
|
|
RP Access Certificate verification failure in issuance flow
|
Block issuance when RP access certificate verification fails
|
|
6 |
Given an issuance flow has been initiated by a Relying Party
When the Wallet processes the RP Access Certificate
And the certificate verification fails
Then the Wallet terminates the issuance interaction
And the Wallet displays a notification informs the Wallet user that the issuance has been blocked indicating that the RP could not be verified
And the Wallet displays a clear notification to the Wallet user that no information about the Wallet user has been shared
|
FAILURE
|
|
RP Access Certificate verification failure in presentation flow
|
Block presentation when RP access certificate verification fails
|
|
5 |
Given a presentation flow has been initiated by a Relying Party
When the Wallet processes the RP Access Certificate
And the certificate verification fails
Then the Wallet terminates the presentation interaction
And the Wallet displays a clear notification to the Wallet user that no information about the Wallet user has been shared
|
SUCCESS
|
|
One-time-use attestation issuance under Method A (once_only)
|
User sees a normal credential after issuance
|
|
3 |
Given the issuer has issued a new batch of one time use credentials to my wallet
When I open my wallet
Then I see the credential displayed like any other credential
|
SUCCESS
|
|
One-time-use attestation issuance under Method A (once_only)
|
User can present the credential without noticing special behavior
|
|
3 |
Given I hold a one time use credential with four of four uses remaining
When I present the credential to a verifier
Then the presentation completes successfully with no unusual prompts or steps
|
SUCCESS
|
|
One-time-use attestation issuance under Method A (once_only)
|
Counter is shown after issuance
|
|
3 |
Given the issuer has issued a new batch of four one time use credential instances
When I view the credential in my wallet
Then I see a counter showing four of four remaining
|
SUCCESS
|
|
One-time-use attestation issuance under Method A (once_only)
|
Counter decreases after a successful presentation
|
|
3 |
Given I hold a one time use credential with four of four uses remaining
When I successfully present the credential to a verifier
Then I see the counter update to three of four remaining
|
SUCCESS
|
|
One-time-use attestation issuance under Method A (once_only)
|
Warning indicator appears when only one use is left
|
|
3 |
Given I hold a one time use credential with one of four uses remaining
When I view the credential in my wallet
Then I see an orange warning indicator with an accompanying icon
|
SUCCESS
|
|
One-time-use attestation issuance under Method A (once_only)
|
User is not prompted to act when the warning appears
|
|
3 |
Given I hold a one time use credential with one of four uses remaining and the warning indicator is displayed
When I view the credential in my wallet
Then I am not asked to take any action
|
SUCCESS
|
|
One-time-use attestation issuance under Method A (once_only)
|
Counter resets to full after re-issuance completes
|
|
3 |
Given the wallet has silently reissued a fresh batch of credentials to replace the depleted batch
When I next open my wallet
Then I see the counter showing four of four remaining
|
SUCCESS
|
|
Reusable attestation with silent renewal under Method B (limited_time)
|
User sees a normal credential after issuance
|
|
4 |
Given the issuer has issued a credential under Method B
When I open my wallet
Then I see a single credential instance displayed like any other credential
And the credential has a batch size of one
|
SUCCESS
|
|
Reusable attestation with silent renewal under Method B (limited_time)
|
User can present the credential repeatedly without noticing time-based behavior
|
|
3 |
Given I hold a valid credential issued under Method B
When I present the credential to a verifier multiple times
Then each presentation completes successfully without decreasing the counter of the instances
|
SUCCESS
|
|
Reusable attestation with silent renewal under Method B (limited_time)
|
No timers or countdowns are shown to the user
|
|
3 |
Given I hold a valid credential issued under Method B
When I view the credential in my wallet
Then I do not see any timer, countdown, or expiration warning
|
SUCCESS
|
|
Reusable attestation with silent renewal under Method B (limited_time)
|
Wallet silently refreshes the credential when it nears expiry
|
|
3 |
Given I hold a credential whose remaining lifetime has fallen below the reissue trigger lifetime left threshold
When the wallet checks the credential's remaining lifetime
Then the wallet silently reissues a fresh credential instance without notifying me
|
SUCCESS
|
|
Randomized balanced rotation with silent renewal under Method C (rotating-batch)
|
Credential always displays full availability
|
|
3 |
Given the issuer has issued a batch of N credential instances under Method C
When I view the credential in my wallet
Then I see the counter showing N of N
|
SUCCESS
|
|
Randomized balanced rotation with silent renewal under Method C (rotating-batch)
|
Counter never shows deletion or decreasing values
|
|
3 |
Given I hold a credential backed by a batch of N instances under Method C
When I present the credential repeatedly
Then the counter continues to display N of N and never decreases
|
SUCCESS
|
|
Randomized balanced rotation with silent renewal under Method C (rotating-batch)
|
Wallet silently refreshes the batch when its lifetime is close to ending
|
|
3 |
Given the batch's remaining lifetime has fallen below the reissue trigger lifetime left threshold provided by the issuer
When the wallet checks the batch's remaining lifetime
Then the wallet silently reissues a fresh batch of N instances without notifying me
|
SUCCESS
|
|
Randomized balanced rotation with silent renewal under Method C (rotating-batch)
|
Credential shows full availability after silent renewal
|
|
3 |
Given the wallet has silently reissued a fresh batch to replace the near expiry batch
When I next open my wallet
Then I see the counter showing N of N
|
SUCCESS
|
|
Wallet Interprets Credential Reuse Policy Metadata
|
User sees a normal credential-issuance flow
|
|
3 |
Given the issuer metadata includes a credential reuse policy with at least one supported option
When I proceed through credential issuance
Then I see a normal issuance flow with no additional steps related to reuse behavior
|
SUCCESS
|
|
Wallet Interprets Credential Reuse Policy Metadata
|
User is not asked to choose a reuse behavior
|
|
3 |
Given the issuer metadata includes a credential reuse policy with multiple supported options
When I proceed through credential issuance
Then I am not prompted to select a reuse method
|
SUCCESS
|
|
Wallet Interprets Credential Reuse Policy Metadata
|
Wallet automatically applies the issuer's preferred behavior
|
|
3 |
Given the issuer metadata includes a credential reuse policy with a single option that the wallet supports
When the wallet processes the issuer metadata
Then the wallet silently applies that reuse method to the issued credential
|
SUCCESS
|
|
Wallet Interprets Credential Reuse Policy Metadata
|
Wallet silently selects the first fully supported policy when multiple options exist
|
|
3 |
Given the issuer metadata includes a credential reuse policy listing multiple options in order of preference
When the wallet processes the issuer metadata
Then the wallet silently selects and applies the first option it fully supports
|
FAILURE
|
|
Wallet Interprets Credential Reuse Policy Metadata
|
Wallet falls back to its own default reuse policy in case of no rule
|
|
3 |
Given the issuer metadata does not include a credential reuse policy
When the wallet processes the issuer metadata
Then the wallet does not show an error and it falls back to its own default reuse policy
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
Display all valid combinations
|
|
3 |
Given the user opens the RP request
When the Wallet loads the request
Then it displays all valid credential combinations that satisfy the request
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
Display only valid combinations
|
|
3 |
Given the Wallet contains stored credentials
When the Wallet evaluates possible combinations
Then it displays only valid combinations based on the stored credentials
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
User must select one combination when multiple exist
|
|
3 |
Given more than one valid credential combination exists
When the Wallet displays the combinations
Then the user must select exactly one before continuing
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
Each option shows which credentials will be shared
|
|
3 |
Given the Wallet displays available combinations
When the user views the options
Then each option clearly indicates which credentials will be shared
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
Only one valid combination exists
|
|
3 |
Given only one valid credential combination exists
When the Wallet displays it
Then the user can proceed without making a selection
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
No valid combinations available
|
|
3 |
Given the Wallet does not contain the required credentials
When the Wallet evaluates the request
Then it displays an error message explaining the request cannot be fulfilled
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
Show information that will be shared
|
|
3 |
Given the user has selected a valid combination
When the user proceeds
Then the Wallet shows exactly which information will be shared with the RP
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
Do not show or share unrequested information
|
|
3 |
Given the user proceeds with a valid combination
When the Wallet prepares the data
Then it does not show or share any information not requested by the RP
|
SUCCESS
|
|
Wallet Presents Alternative Credential Combinations from a DCQL Query
|
Canceling the flow
|
|
3 |
Given the user is in the sharing flow
When the user cancels
Then the Wallet returns to the previous screen without sharing any information
|
SUCCESS
|
|
Improve Add Document Flow UI
|
Instances count is not displayed during issuance
|
|
3 |
Given the user is at the Add Document screen
When user attempts to issue an attestation
Then The instances count is not displayed during issuance
|
SUCCESS
|
|
Improve Add Document Flow UI
|
Verify QR button presence
|
|
3 |
Given the user navigates to the Add Document screen
When the user selects from List option
Then a QR button should be visible in the upper right corner
|
SUCCESS
|
|
Improve Authentication Flow UI
|
Verify navigation to Authentication Intro screen
|
|
3 |
Given the user is on the Home page and selects Authenticate
When the user selects either in person or online
Then the title Authenticate my identity is displayed
|
SUCCESS
|
|
Improve Authentication Flow UI
|
Verify informative text
|
|
3 |
Given the user is on the Home page and selects Authenticate
When the user selects online
Then the informative text Scan a QR code provided from an interacting party to authenticate your identity is displayed
|
SUCCESS
|
|
User document management experience
|
Verify + button color in iOS
|
|
4 |
Given the user launches the app on iOS
When the Document List screen is displayed
Then the + button should be visible
And the + button color should be blue
|
SUCCESS
|
|
User document management experience
|
Verify search field label
|
|
2 |
Given the user is on the Document List screen
Then the search field should display the label Search
|
SUCCESS
|
|
User document management experience
|
Remaining instances section
|
|
3 |
Given the user opens a document details screen
When the user navigates at the bottom of the screen
Then the remaining instances section is displayed at the bottom of the screen
|
SUCCESS
|
|
User document management experience
|
Verify Eye button placement and text
|
|
2 |
Given the user is on the Document Details screen
Then the Eye button should be placed next to Document Details text
|
SUCCESS
|
|
User document management experience
|
The Issuer details card is displayed on top
|
|
3 |
Given the user is on the Document Details screen
When the user observes the top of the screen
Then the Issuer details card is displayed on top
|
SUCCESS
|
|
User document management experience
|
Verify filters grouping
|
|
3 |
Given the user opens the Filter screen on iOS
When the filters are displayed
Then filters should be grouped by category
|
SUCCESS
|
|
User document management experience
|
Verify filter controls use switches
|
|
3 |
Given the user is on the Filter screen on iOS
When the filters are displayed
Then all filter options should use switches instead of checkboxes
|
SUCCESS
|
|
User document management experience
|
Verify check button in header
|
|
3 |
Given the user opens the Filter screen on iOS
Then a check button should be visible in the upper right corner
And the Apply button should not be visible
|
SUCCESS
|
|
Improve History Flow UI
|
Verify Transactions label is updated
|
|
3 |
Given the user navigates through the application
Then all instances of Transactions should be renamed to History
And the corresponding icon should be updated
|
SUCCESS
|
|
Improve History Flow UI
|
Verify search field label
|
|
2 |
Given the user is on the History screen
Then the search field should display the label Search
|
SUCCESS
|
|
Improve History Flow UI
|
Verify filters grouping on iOS
|
|
3 |
Given the user opens the Filter screen on iOS
When the filters are displayed
Then filters should be grouped by category
|
SUCCESS
|
|
Improve History Flow UI
|
Verify filter controls use switches on iOS
|
|
3 |
Given the user is on the Filter screen on iOS
When the filters are displayed
Then all filter options should use switches instead of checkboxes
|
SUCCESS
|
|
Improve My Wallet Flow UI
|
Verify Change PIN screen title
|
|
3 |
Given the user navigates to the Settings Option button
When the user navigates to the Change PIN screen
Then the screen title is displayed as Change PIN
|
SUCCESS
|
|
Improve My Wallet Flow UI
|
Verify prompt appears when tapping Back
|
|
3 |
Given the user is on the Change PIN screen
When the user taps the Back button
Then An informational prompt appears with the text: Cancel PIN change?
|
SUCCESS
|
|
User onboarding experience
|
Logo consistency across onboarding
|
|
3 |
Given the user opens the app either for the first time, or for next time
When the user navigates through onboarding screens
Then the updated logo is displayed on all screens
|
SUCCESS
|
|
User onboarding experience
|
Type PIN screen informational text
|
|
3 |
Given the user opens the app for the first time
When the user navigates to the Welcome to your wallet screen
Then the following text is displayed: Secure your wallet with a PIN code and connect to your National System below the Welcome to your Wallet
|
SUCCESS
|
|
User onboarding experience
|
Type PIN screen label
|
|
3 |
Given the user opens the app for the first time
When the user navigates to the Welcome to your wallet screen
Then the Label Type a PIN is displayed above the PIN input fields
|
SUCCESS
|
|
User onboarding experience
|
Confirm PIN screen informational text
|
|
4 |
Given the user types a PIN for a first time
When confirm PIN screen is displayed
Then this text is displayed Secure your wallet with a PIN code and connect to your National System
And Label Confirm PIN is displayed above the input fields
|
SUCCESS
|
|
User onboarding experience
|
Home tab greeting updated
|
|
3 |
Given the user opens the app again after issuing a PID
When user navigates to the Home tab
Then the greeting is updated to Welcome, [Name]
|
SUCCESS
|
|
User onboarding experience
|
Home tab greeting update
|
|
3 |
Given the user opens the app
When user navigates to the Home tab
Then the hyperlink Learn more is a button
|
SUCCESS
|