Launching AWS Payment Cryptography
Problem
AWS customers have a multitude of use cases for generating and using cryptographic keys for a range of application types. However, some industries are subject to enhanced regulation, leading to more stringent compliance requirements and higher standards, resulting in limited options when securely building systems. This is particularly true when trying to leverage the scalability, elasticity, convenience, and speed of cloud architecture.
Result
AWS Payment Cryptography is a tailored service to meet high-standard cryptography needs from acquirers, payment facilitators, networks, switches, processors and banks. These customers have specific needs in viewing configuration information, ensuring auditability and traceability, and creating, managing, securing, and deleting keys. The service is generally available as of June 12, 2023.
Industry
Cloud security, Cryptography, Fintech
Duration
Jan 2023 — June 2023
Product
Web service
My Roles
UX design
UI & Interaction design
Developer support
(5+ person team)
Discovery
1-1 interviews with industry clients and a closed, service-only (i.e. API/CLI) beta turned up specific use cases, workflows, pain points, and feature requests.
In addition, I conducted a review of industry standards and competitors, although this was to be a relatively new service type. Many would-be customers had home-grown solutions in order to adhere to Payment Card Industry (PCI) standards and rules.
The main incentive to move to a cloud-based service would be the provisioned management of payments HSMs, or hardware security modules. Currently, managing these HSMs is:
- Cumbersome
- Expensive
- Time-consuming
- Error-prone
Moving to an AWS solution would require support of workflows to:
- Generate and test keys
- Audit key compliance
- Verify key check values
- Generally manage and access key information
Mapping Assumptions
With the service breaking new ground, especially in having a GUI, I mapped assumptions made by myself and other stakeholders, in order to decide how strongly to factor those assumptions into UX artifacts and design decisions.
[Importance ranking relates to console only, not service in general]
Defining Users & Use Cases
After analyzing findings and consulting with finance cryptography SMEs several insights were drawn up that defined our audience for the initial service launch. Due to the constrained target customer group, we could more reliably pinpoint persona roles and use cases.
Primary users were grouped into:
- Key Manager [Produce and manage keys]
- Compliance Manager [Uphold key configuration/usage standards]
- Developer/DevOps [Write code that leverages keys for secure operation]
Design Decisions
UX process began as an effort to develop a presentation layer for the API at launch. Designs were also prepared for create, delete, enable/disable, and tag/alias modification operations, scoped for a "fast-follow-up" period 60-90 days after launch.
View Key Configuration
Emphasis was placed on ensuring that different personas had access to different views of the keys contained in the service. A very robust API was developed and fully visualized in the console, with default view providing a preview of both key status and configuration.
Create a New Key
Our primary UX goal for customers creating a new key was to simplify and provide context to the many types of possible key configurations and to their relative purposes. To support customers in their potential confusion, we structured form fields logically, so that valid configurations were the only ones displayed. We also provided visible field descriptions, help panel buttons, as well as direct links to documentation pages meant to help customers with exactly this task.
Design iteration: Delete or Disable a Key
Deleting keys is considered a destructive action with rippling effects due to unrecoverable data implications, so much so that the service also offers a "Disable" option for keys no longer in active use. We made it abundantly clear to customers deleting a key that the action was irreversible and the data encrypted under it unrecoverable with a secondary confirmation pattern, and then required customers to schedule a waiting period during which the key could be recovered (min. 3 days).
Initial design was a modal popup, but a product stakeholder questioned if the flow might need even more additional warning, because risks could include unrecoverable funds or major security holes.
As a result, I made the decision to make the flow a dedicated page to mitigate risk of user error due to resources overflowing the modal box. Basically, ensuring that a user would need to scroll past and skim every resource about to be scheduled for deletion.
Edit Tags/Edit Aliases
Tags and Aliases served similar purposes, and so were addressed in similar ways. Multiple of each were likely in scaled resource organization use cases, and we allowed customers to mass edit via attribute/tag editors.
Tags
Aliases
Cloudscape Design System Review
A review process would approve the launch of the T1 service. I worked with engineering & product leads to scope presented designs to account for revision, development, and QA/AppSec prior to the planned launch date.
Through close collaboration with the reviewers, including upper-level design managers and reps from the Cloudscape Design System team, I fine-tuned designs to balance the best UX for the service itself with external consistency to the rest of the AWS platform.
Conclusion
Ultimately, we succeeded in introducing a new tool that serves a smaller but potentially highly-loyal audience, as well as increasing AWS' presence as a provider of cryptographic services for different purposes.
The quickly-planned multiple-stage launch process provided a great opportunity to practice advanced project management, and to work with other leads in directing objectives around larger-scale timelines.
