diff --git a/attestations-ui-2025/1-Attestations style guide - cover.pdf b/attestations-ui-2025/1-Attestations style guide - cover.pdf new file mode 100644 index 0000000..52a2f38 Binary files /dev/null and b/attestations-ui-2025/1-Attestations style guide - cover.pdf differ diff --git a/attestations-ui-2025/1-attestations-style-guide-intro-and-background.md b/attestations-ui-2025/1-attestations-style-guide-intro-and-background.md new file mode 100644 index 0000000..dc71f05 --- /dev/null +++ b/attestations-ui-2025/1-attestations-style-guide-intro-and-background.md @@ -0,0 +1,230 @@ +# Attestations Style Guide Intro and Background + +## Welcome to the style guide for displaying attestations on package repositories. + +This guide presents the findings from our user research, including summaries, clarifications, and rationale. Based on this, we provide 'good first' UI examples and recommendations to guide initial adoption by three software package registries: PyPI, RubyGems.org, and npm. We're highlighting these registeries because they are among the most widely used and actively evolving open source package ecosystems, each with distinct approaches, and each serving a wide range of user and project types. Their prominence within the broader software supply chain makes them representative models for attestation UX and documentation. + +This project was initiated by the OpenSSF Securing Software Repositories working group to improve the user experience (UX) of attestations. For more context, you can review the initial request and the project task board: + +• Initial Request: [https://github.com/ossf/tac/issues/424](https://github.com/ossf/tac/issues/424) +• Project Task Board: [https://github.com/orgs/ossf/projects/36](https://github.com/orgs/ossf/projects/36) + +While we focused on only the three registries for actionable detail, the guidance and templates here are designed to be adaptable. So we encourage maintainers and contributors from other ecosystems to apply and extend these principles for fostering secure and consistent repository practices to their chosen registeries. In fact, these recommendations are intended to be flexible enough to also work outside of package registry page layouts and should be iterated on and improved. For information on how to extend this work, please see the contribution page of this guide. + +## Work plan & team + +The public workplan can be seen here: https://github.com/orgs/ossf/projects/36?pane=issue&itemId=115907793&issue=ossf%7Cwg-securing-software-repos%7C72 + +The individuals /organisations involved in this project are listed below. + +- Open SSF +- OpenSSF Securing Software Repositories working group +- Kabu Creative +- Superbloom Design +- Implementation partners TBC +- Our 15+ User Testers from the OSS community + +## Content + +This style guide contains the following sections: + +1. How to use +2. Lowest UI requirements (Level A) +3. Medium UI requirements (Level AA) +4. Highest UI requirements (Level AAA) +5. Attestations, Build, Source, Integrity UI in detail +6. Additional signals of trust +7. Icons +8. Hyperlinks and linking information +9. Documentation +10. Language localisation +11. Contribution information + +## Research + +We conducted three phases of research with users and additionally secondary (desk) research throughout the project. + +**Phase 1** The first phase was exploratory research focused on how users find security information on packages and their initial perceptions of attestations. Our methods were based on user interviews, behavioral observation, and feedback on existing, live content. + +**Phase 2 & 3** The second and third phases involved usability testing the initial UI designs for attestations. We also gathered feedback on the accessibility and clarity of the proposed documentation. + +Research documentation: https://github.com/orgs/ossf/projects/36/views/3 + +More on secondary research: https://www.nngroup.com/articles/secondary-research-in-ux + +## Methodology + +With the exploratory research we followed contexual inquiry and semi-structured interview methods. [https://www.nngroup.com/articles/user-interviews/](https://www.nngroup.com/articles/user-interviews/) & [https://www.nngroup.com/articles/contextual-inquiry/](https://www.nngroup.com/articles/contextual-inquiry/) + +To synthesize our findings from the exploratory research we used Thematic analysis and Affinity Diagraming [https://www.nngroup.com/articles/affinity-diagram/](https://www.nngroup.com/articles/affinity-diagram/) + +Finally, we used usability testing and preference analysis to evaluate the proposed designs and documentation (see [https://www.nngroup.com/articles/usability-testing-101/](https://www.nngroup.com/articles/usability-testing-101/) and [https://www.youtube.com/watch?v=-XYTk5MVvK0](https://www.youtube.com/watch?v=-XYTk5MVvK0) ). + + +## Attestations personas + +To guide our research, we developed three personas to represent the types of users who might interact with attestations on package repositories. Each persona includes information about the user's role, goals, frustrations, and desired project outcomes. + +1. The Security Architect (concerned / informed) +Represents a security expert who is highly informed about attestations and has deep foundational knowledge of software security. This user's primary goal is securing the software supply chain as a key part of their role. + +2. The Pragmatic Developer (somewhat concerned and somewhat informed) +Represents a user who is aware of attestations but must balance security against many competing priorities. They may be an engineering team lead, senior software engineer, or DevOps engineer responsible for building and shipping products. + +3. The Incidental Consumer (not concerned, not informed) +Represents a user who is unaware of attestations, because for them, code is a tool, not their profession. They may be a data analyst using Python, a designer using a JavaScript static site generator, a hobbyist, or a student following a tutorial. + +View the full personas here: +[https://github.com/ossf/wg-securing-software-repos/issues/70](https://github.com/ossf/wg-securing-software-repos/issues/70) + +More on personas: +[https://www.nngroup.com/articles/personas-study-guide/](https://www.nngroup.com/articles/personas-study-guide/]) + +## Research Results + +You can find raw, unedited notes from our user research here: + +[https://github.com/ossf/wg-securing-software-repos/issues/66](https://github.com/ossf/wg-securing-software-repos/issues/66) + +[https://github.com/ossf/wg-securing-software-repos/issues/83](https://github.com/ossf/wg-securing-software-repos/issues/83) + +The insights from this research informed the recommendations in this guide, including findings about: + +1. User interface preferences +2. How users assess package + safety +3. Comprehension of technical + terms and concepts +4. Where and why users seek + information +5. Opinions on attestations, + their impact on trust and what other information, nearby attestations, help the trust of attestations. + +![A screenshot of the research synthesis that can be seen in full in the open source penpot files](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/research-synthesis.png "A screenshot of the research synthesis that can be seen in full in the open source penpot files") + +## How to use the style guide + +The following pages in this style guide provide recommendations for displaying User Interface (UI) elements for attestations. We also identify and share additional elements that users found useful for building trust in the safety, security, and integrity of the packages they install. + +All recommendations are grounded in user research and testing, conducted with users who reflect each of the personas detailed in the style guide introduction. + +We understand that each package registry has unique structural and design considerations. Therefore, the extent to which these guidelines are implemented is at the discretion of each registry. We've scaled our UI recommendations to accommodate various section sizes and the distinct ways packages are presented. For example, some registries embed extensive READMEs directly on package pages, pushing down other content. Others feature wider main sections with smaller sidebars. Others include infrastructure for multiple pages or menus, making it easier to integrate new pages and sections. + +We recommend starting with the implementation that best suits your package registry/platform while maintaining the consistency of your existing visual design system. We advise against altering core branding elements such as colors, hyperlink styling, or border properties (size, color, radius). Our recommended UI elements are designed for flexibility, and should be integrated into most existing systems without requiring fundamental changes to your visual language. There is always the opportunity to contribute a new iteration along with your rationale. + +In the spirit of open source, and where practical, all project materials - from research protocols and personas to anonymized user testing notes and UI designs in Penpot - are publicly available. Please refer to our contribution pages for more details. + +## Best practices for documenting attestations + +**Attestations documentation should:** + +- Help package consumers understand attestations, including what they are, how they work, and what their limitations are + +- Help package consumers understand attestations within the context of other security features and practices + +- Direct package maintainers towards workflows that generate attestations + +For attestation documentation to be most successful, we recommend documentation authors follow these seven principles: + +**1. Use key terms consistently** + +To ensure clarity and consistency for attestation consumers, use key terms as defined below. Adhering to these standards prevents user confusion across packaging ecosystems. + +Attestation +- _Definition_: A statement of signed facts (or metadata) about a software artifact +- _Do_: Use this as the general term for a signed claim. It is the foundation for more specific +terms like "Build Provenance Attestation" + +Build Provenance +- _Definition_: A verifiable trail of evidence for a package's origin. It answers where a package came from and how it was built +- _Do_: Clarify this term in headings or text when the concept might be new to users +- _Example_: "Verifying build provenance (package origin)" + +Build Provenance Attestation +- _Definition_: A specific type of attestation that describes how, when, and where a package was built +- _Do_: Clarify the relationship between attestations and build provenance using this term +- _Example_: "A build provenance attestation describes how, when, and where a package was built." + +Transparency Log Entry +- _Definition_: The tamper-proof record of the build provenance attestation saved to a public ledger +- _Do_: Use "transparency log entry" to describe how an attestation is recorded +- _Example_: "Each attestation is recorded in a public ledger as transparency log entry, which is a permanent, auditable record that cannot be changed." + +Verified +- _Definition_: The process that a package repository takes when accepting an attestation from a build platform, ensuring the attestation's source matches the maintainer's configuration +- _Do_: Use "verified" to describe the repository's automated check during package upload +- _Example_: "PyPI verifies this attestation at upload time, confirming that the identity matches what the maintainer previously configured for Trusted Publishing." + +**2. Structure documentation around user roles** + +Package consumers and maintainers require (and have) different levels of knowledge about security concepts and features, including attestations. + +Content for package consumers should be separated from content for package maintainers, surfacing relevant and actionable information to each audience. + +Structure the Information Architecture around user roles, using clear, top-level sections like "Using This Repository" (for consumers) and "Publishing Packages" (for maintainers). + +**3. Provide content to help package consumers understand attestations within the context of other security features** + +Attestations are only one part of a larger security story. To be effective, documentation must place them in context, helping users build a holistic mental model of risk. + +Documentation for package consumers should explain how security practices and features work together as a layered defense. It should be structured around the fundamental questions a user has about risk: + +1. Can I trust the source code? +Explaining signals like project activity, vulnerability scanning, etc. + +2. Where did this package come from and how was it made? +Explaining build provenance and attestations + +3. Did I download the same file that is hosted on the package repository? +Explaining checksums and integrity + +**4. Warn package consumers that packages are not secure by default** + +Some package consumers hold the incorrect assumption that because a package is published on an official repository it is secure and/or trustworthy. To combat this, include disclaimers on pages for package consumers, directing users towards security documentation. + +Example from PyPI: +_Warning: Installing packages from PyPI means running third-party code, which carries inherent security risks. Before installing any package, we strongly recommend reading our Package security guide._ + +**5. Normalize secure-by-default publishing workflows** + +Documentation should be opinionated in favor of security. The most secure method for any task should be presented as the canonical, recommended path. + +When writing documentation about publishing packages, prominently feature the most secure, automated publishing method that generates attestations. This should be the first and most detailed workflow described, establishing it as the modern standard. + +Where applicable, clearly and explicitly state that using the recommended workflow confers the benefit of generating provenance attestations automatically. This makes adopting the secure workflow more compelling. + +Legacy methods that do not produce attestations should be explicitly marked as "deprecated" or "for advanced use cases" to guide users away from them. + +**6. Explain common security attacks and how they are mitigated** + +Transparently list the threats the user faces (e.g., Typosquatting, Account Takeover) and what they can do to protect themselves. Explain platform-level features that mitigate common attacks, including the role of Trusted Publishing and attestations. + +Provide clear reporting channels for users concerned about the security of an individual package or the package repository as a whole. + +**7. Be transparent about limitations and set clear expectations** + +Documentation must be upfront about the scope and limitations of the security practices or features it describes. + +State clearly that an attestation proves build provenance (where a file came from) but does not vouch for the code's safety (that the code is free of bugs or vulnerabilities). Explain that trusting an attestation means implicitly trusting the tooling and authority that issued it. + +Be transparent about the readiness of downstream tooling. Where applicable, highlight that automated attestation verification is not yet ready in common package managers. + +## Style guide: Contributing or iterating on this work + +This is the first iteration of UI recommendations for attestations and supportive relevant information for all levels of developer persona understanding. + +We encourage continued contribution to this work, including: + +1. Continued user research that can expand on and/or follow the guidelines set out in previous User Research: [https://github.com/ossf/wg-securing-software-repos/issues/82](https://github.com/ossf/wg-securing-software-repos/issues/82) and [https://github.com/ossf/wg-securing-software-repos/issues/66](https://github.com/ossf/wg-securing-software-repos/issues/82) + +2. Developing alternate, refined and appropriate UI iterations that are tested with users for clarity and usefullness in terms of supporting their safety and security trust in packages: [https://github.com/ossf/wg-securing-software-repos/issues/65](https://github.com/ossf/wg-securing-software-repos/issues/82) + +3. Improving and iteration on documentaton templates and examples: [https://repos.openssf.org/](https://github.com/ossf/wg-securing-software-repos/issues/82) + +4. Enhancing the graphic design of unique icons and developing a specific attestation logo/symbol. (see the Icons page of this style guide). + +5. Any other contributions and/or recommendations can be brought to the OpenSSF Working Group on Securing Software Repositories [https://github.com/ossf/wg-securing-software-repos](https://github.com/ossf/wg-securing-software-repos/issues/82) + + + + diff --git a/attestations-ui-2025/2-Style guide_ Level A - Lowest requirements - 1.pdf b/attestations-ui-2025/2-Style guide_ Level A - Lowest requirements - 1.pdf new file mode 100644 index 0000000..b05e4f6 Binary files /dev/null and b/attestations-ui-2025/2-Style guide_ Level A - Lowest requirements - 1.pdf differ diff --git a/attestations-ui-2025/2-style-guide-level-a-lowest-requiremments.md b/attestations-ui-2025/2-style-guide-level-a-lowest-requiremments.md new file mode 100644 index 0000000..82b342b --- /dev/null +++ b/attestations-ui-2025/2-style-guide-level-a-lowest-requiremments.md @@ -0,0 +1,143 @@ +# Style guide: Level A - Lowest requirements + +This section of the style guide defines the minimum (level A) requirements for displaying attestation information on package registries: + +1. Attestation information should be placed in a visible, but not overpowering, location on registry pages +2. It should contain enough information to make attestations understandable to a broad variety of + users (as detailed in this introduction) +3. It must not impede users from achieving their primary goal, e.g., “finding out if this package is the best choice for the intended purpose.” + +These Level A requirements describe a set of minimal, collapsible, and distinct UI "panels" with icons and headings appropriate to the information that can be expanded in them. + +Alongside the following UI examples, variants, and recommendation we will reference and explain the user research rationale and insight the led to that decision. + +You can find the unedited user research sessions on the open issues related to this project: + +• User Testing Sessions Issue #82: [https://github.com/ossf/wg-securing-software-repos/issues/82](https://github.com/ossf/wg-securing-software-repos/issues/82) +• Persona & Research Issue #66: [https://github.com/ossf/wg-securing-software-repos/issues/66](https://github.com/ossf/wg-securing-software-repos/issues/66) + +If you'd like to contribute, comment or iterate on this work then please see the design contribution documentation. + +--- + +![A screenshot of a UI example of the lowest level A requirements for visualising attestation information](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/lowest-requirements-1.png "A screenshot of a UI example of the lowest level A requirements for visualising attestation information") + +This is intended to sit in a main section of a webpage that might use a three-column layout--the main section occupying two-thirds and a sidebar occupying one-third of the width. + +In this version, each icon and heading is seperated by a vertical bar/pipe that spans approximately 75% of the total height of the container box. + +The panels can have a stroke or a drop shadow effect, yet should be adjusted to match whatever the platform's design system or styles. + +While this panel can be used as-is with no interactive expansion, we advise against this. + +Since this component is a panel each heading should be clickable to expand additional info underneath. The expand/collapse interaction should be eased and not instantaneous for users. + +The expanded sections have a border stroke and also a background color. You can omit one or the other as long as the expanded section of the panel is in close proximity to appropriate heading. + +Depending on the width space you have available you can increase the width of both the panel and the expanded section. Be sure to use minimum text/font sizing available per platform for legibility. + +With this Level A component styling, use words and letters conservatively in the attestation statement, balancing clarity of statement with space available. If needed, the attestation can be placed underneath at full width to accomodate complex statements (UI example on next page). + +![A screenshot of a UI example detailing icon information](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/lowest-requirements-2.png "A screenshot of a UI example detailing icon information") + +re. the package icon or source code icon. Either can be used interchangeably for this information. Users connected both with this info in research. + +![A screenshot of a UI example detailing a verion of the lowest level UI that has seperated 'boxes' and what a full width attestation 'box' could look like](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/lowest-requirements-3.png "A screenshot of a UI example detailing a verion of the lowest level UI that has seperated 'boxes' and what a full width attestation 'box' could look like") + +**Signed by messages:** +"Signed by" messages should be bold to indicate importance. They can flow over two lines but three lines should be avoided. + +**Links styling and icons:** +In this example, as in the last page, we've used PyPI's visual styling with blue hyperlinks and an external link icon next to each link. Both the icon colour and font can be changed to match existing styles. The use of an "open in a new tab" icon is optional. + +The component variant to the left here shows when the panels are not grouped, instead they're separate panels aligned in a row. Their expandable sections still can be activated. Some platforms may prefer separated panels like this for their pages' global styles and/or to look more like buttons that can be interacted with. + +![A screenshot of a UI example detailing a verion of the lowest level UI with expanded tabs/details using npm style](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/lowest-requirements-4.png "A screenshot of a UI example detailing a verion of the lowest level UI with expanded tabs/details using npm style") + +In this example, we've used npm visual styles. + +**Link labels** +The links displayed here have all been carefully tested with users. In our research, we found that users expected the following information to be displayed near the attestation statement: + +1. Source repo & source commit +2. Build commit & build logs +3. Transparency log (within the attestation statement section) + +We recommend left-aligning link labels, allowing them to span over two lines where required. + +**Enhancing user confidence** +Additional recommendations to help users feel confident about the security of a package are detailed in the medium (level AA) and highest (level AAA) UI recommendations. + +Users also rely on "social proof" (number of downloads, maintainers, recognizable project names) typically found on registry pages. Hashes/checksums also encourage confidence, but only if users recognize them and understand their function. + +![A screenshot of a UI example detailing a verion of the lowest level UI with expanded tabs/details using RubyGems style](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/lowest-requirements-5.png "A screenshot of a UI example detailing a verion of the lowest level UI with expanded tabs/details using RubyGems style") + +This example uses visual styles from RubyGems. + +**How different personas understand this UI** +The 'Security architect' persona already knows what information is needed to feel confident about a package's security. For them, simple visual and text indicators (e.g., this UI in its collapsed state) are typically sufficient; expanding to see more information confirms their existing knowledge. + +For 'Pragmatic Developers' and 'Incidental User' personas, simple visual and text indicators (e.g., this UI in its collapsed state) are not helpful and can lead the user to guess what the information means (either correctly or incorrectly). + +These users need to see this UI in its expanded state to understand what attestations communicate. Viewing the detailed information typically prompts them to explore further and piece together an understanding of package security. Providing additional documentation links can also help these users learn. + +![A screenshot of where the lowest level A UI should ideally be situated on a webpage](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/lowest-requirements-webpage-placement-1.png "A screenshot of where the lowest level A UI should ideally be situated on a webpage") + +The positioning of these minimal elements on a page is also critical. The next page in this style guide illustrates their optimal positioning within each example package registry (please note that the next page is large, and you may need to scroll to find the appropriate UI example). + +Ideally, this UI should not reside at the bottom of a page, particularly on platforms where extensive README files push other critical information downwards. User feedback indicates a strong preference to understand a package's core functionality before encountering security or attestation details. + +Placing these UI elements at the top of a page or within a header component presents a dilemma: + +1. Prioritization: It effectively "forces" (as users described) immediate + consideration of security. +2. Interruption: It disrupts the user's primary goal of quickly assessing the + package's purpose. + +While promoting security awareness is important, it shouldn't overshadow essential package information. Therefore, while placing these elements in the first scroll/fold can prioritize security, it's generally more effective to position them at the top of the second scroll/fold. This aligns better with user expectations and their natural information discovery journey. + +Please open the following annotated UI full webpage examples in an image viewer of your choice. This image is large at 5.7MB and 11300x12722 pixel canvas. There is also a .pdf file. + +[https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/ui-development-lowest-ui-version-a-level.png](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/ui-development-lowest-ui-version-a-level.png) + +[https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/ui-development-lowest-ui-version-a-level.pdf](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/ui-development-lowest-ui-version-a-level.pdf) + +The following text is included in the annotated image file: + +Critical information about the package has been retained at the top of the page, along with information that all users prioritize—download numbers and usage metrics. These are the primary indicators of trust in a package: that “many eyes” have seen and used the package. For most developers, this is enough to justify using a package. + +For packages that are less popular or less established, users cannot rely on this kind of “big numbers” information. In these cases, they look for authoritative information from trusted sources such as the registry website, authority bodies like software foundations, or maintainers with a reputable name. + +Some users not only rely on the aforementioned information, but also personally check security details such as matching hashes and keys, reviewing source code, and investigating the build process and origin pathways. These users typically aim to avoid risks such as introducing vulnerabilities that could expose user data (like financial or other private information), or put systems—such as company or university infrastructure—at risk. + +From our research, only certain users understood what a 256 checksum and similar information are for, or how to use them. Therefore, placing attestation UI elements related to more complex or less commonly known security terms or processes can help users better understand these difficult concepts. By positioning the UI above the checksum, users are less likely to “check out” and stop paying attention to the page when they encounter unfamiliar terms they do not recognize or have time to investigate. + +In this example from npm, you can see that the package exposes a lot of README information that the maintainers have worked hard on. During testing, users found this reasonable but somewhat over-engineered. They had difficulty finding the basic information they needed and relied heavily on the sidebar for the critical details required to decide whether to use the package. + +Based on these findings, we believe that for package pages like this, presenting attestation information in the sidebar is best. Sidebar options are discussed in more detail later in the style guide. + +If possible there should be a way for users to differentiate between maintainer provided information from the README versus index-controlled content such as the key words and provenance information. + +We recommend adding a visual break, such as a divider line or heading, here so that people understand what type of information they are looking at. + +The first place attestation information can be added is above the license information. Since the license is also detailed in the sidebar, users are generally comfortable with attestation content being positioned as high as possible on these types of pages. However, be aware that the likelihood of users discovering attestation information here is low. Most users will not scroll through these long README pages unless they are specifically searching for security, provenance, or attestation details they cannot find elsewhere on the page or in a different tab. More commonly, users will go to the project repository to find information such as build logs, commit files, source code, and so on. + +On this page (and others), you may find that detailed information is repeated in areas we suggest as supporting the attestation statement. From our user research and UI testing, we discovered that users did not find this confusing or off-putting. Instead, users were encouraged by “duplicate” information and saw no problem with encountering the same link in multiple places or seeing documentation in more than one section. + +The researchers’ hypothesis is that users seek information in a compartmentalized way. When users are specifically looking for attestation or security-related information about package builds, they tend not to notice other information not labeled as such, unless they deliberately switch their focus. + +When users did notice that the same or similar information appeared in two sections or locations, they felt more confident in the package page’s diligence at repeating critical information that might otherwise be missed. Their trust was also reinforced when two matching links appeared in different places. This response was connected to a general distrust of package information pages on registries. As one user stated, “They can put whatever they want on here, can’t they? Who even approves and checks that it’s true and accurate?” Seeing the same link repeated in two places gave some users more confidence—if a source commit is linked in area 1 and area 2 and they match, it suggests someone is ensuring consistency. + +Therefore, repeating information should not be a concern for platforms implementing this approach, but it is critical that the same headings, terms, labels, and destination links are used consistently across different locations + +The first place attestation information can be added is above the license information. Since the license is also detailed in the sidebar, users are generally comfortable with attestation content being positioned as high as possible on these pages. However, be aware that the likelihood of users discovering attestation information here is low. Most users will not scroll through these long README pages unless they are specifically looking for security, provenance, or attestation information that they cannot find elsewhere on the page or in a different tab. More commonly, users will go to the project repository to find information such as build logs, commit files, source code, and so on. + +We recommend that there be a visual divider or way for the user to distinguish when maintainer provided content (eg. the project description) ends and index-controlled content (eg. security information) begins. This divider line follows the existing style of the site. + +Here, you can see that the separated elements can either span the full width of the available space in the main section, or they can take up only the minimum amount of space needed by the expandable sections to display additional information. + +You’ll also notice that this information is placed underneath the project description. This positioning risks users misinterpreting the information as belonging to the previous heading (in this case, Code of Conduct). In these situations, we encourage using a divider and a heading such as “Security,” “Attestation,” “Provenance,” or another relevant heading of your choice. We also recommend, specifically for PyPI, that some information typically found in the Download Files section is difficult for unfamiliar users (and even some regular visitors) to find. If the attestation information also included any SHA/checksum details and additional information related to these topics, then placing this section at the bottom of the project description would be less surprising. + +Note: For projects with long descriptions, this information may be pushed far down the page and not be as accessible to users. If this is of particular concern, we recommend implementing a dedicated Security page such as in the Highest UI version - AAA grade. + +In contrast to the comments in the above PyPI mock-up, when expanded, this section maintains its own relevance much more strongly and may not require moving information from the download files section. diff --git a/attestations-ui-2025/3-Style guide_ Level AA - Medium requirements - 1.pdf b/attestations-ui-2025/3-Style guide_ Level AA - Medium requirements - 1.pdf new file mode 100644 index 0000000..82acf74 Binary files /dev/null and b/attestations-ui-2025/3-Style guide_ Level AA - Medium requirements - 1.pdf differ diff --git a/attestations-ui-2025/3-style-guide-level-aa-medium-requiremments.md b/attestations-ui-2025/3-style-guide-level-aa-medium-requiremments.md new file mode 100644 index 0000000..2593f19 --- /dev/null +++ b/attestations-ui-2025/3-style-guide-level-aa-medium-requiremments.md @@ -0,0 +1,122 @@ +# Style guide: Level AA - Medium + +This section of the style guide defines the medium (Level AA) requirements for displaying attestation information on package registries, aiming to strengthen users' sense of security and trust in a package's build integrity. + +Package repositories opting to implement these recommendations will need to allocate more visual space within their user interfaces. This approach expands upon the information introduced in the lowest (Level A) requirements by proactively revealing additional details, source links, and clear pathways for users to explore and better understand attestation and related information. + +There are variants for medium-level requirements: + +1. **Three-Card Layout**: Information is presented in distinct "cards" or modules. Each card includes + icons, headings, labeled source links, and links to documentation (where relevant). This variant + typically features three cards, with flexibility for additional cards as needed. + +2. **Four (Larger) Card Layout**: Designed for package registries with more visual space, this variant + utilizes larger card designs. It typically features four cards, with flexibility for additional cards + as needed. + +During user testing, we found that variants one and two (three card and four card layouts) were most effective in helping users explore the safety, security and integrity of a package, along with the included links. + +User research notes from this project, please see: +• [https://github.com/ossf/wg-securing-software-repos/issues/66](https://github.com/ossf/wg-securing-software-repos/issues/66) + Notes from user tests focused on evaluating attestation user interfaces for clarity and user preference. + + +![A screenshot of a UI example of the medium level AA requirements for visualising attestation information](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/medium-requirements-1.png "A screenshot of a UI example of the medium level AA requirements for visualising attestation information") +Box width = 200px Height = 160px in example + +Cards are designed so that three should fit in most main page widths for platforms and boxes can be stacked e.g. if there are two or more attestations the fourth box can go below the Source card etc. + +The detail here is the same as the expanded version of the minimal, Level A component. Differences are that the package name, version number and box icon has been swapped with a browser and code brackets icon with the heading of "Source". To users, the package icon, name and the source icon and label source mean the same/similar enough terms and the associating information of repo and source commit contextualise the heading for them. + +Later in this style guide we'll clarify the use of the terms like "build confirmed" versus the use of "verification". + +Again, the Build Confirmed card contains the build commit (for the version available on the page/platform) and the build logs. Please note these example links may not be exactly accurate link destinations. + +The Transparency log link can either be the URL or a hyperlink. +More detail about hyperlinks can be found in the hyperlinks page of this style guide. + +![A screenshot of a UI example of the medium level AA requirements for visualising attestation information with larger 'box' size](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/medium-requirements-2.png "A screenshot of a UI example of the medium level AA requirements for visualising attestation information with larger 'box' size") + +Box width = 260px Height = 200px in example + +Again, these cards are designed to be stacked and so that two should fit within the width of the main content area of standard page layouts. For example, if there are two or more attestations they can form a row of two: the Source card can go next to the Build Confirmed card, and the Integrity card can occupy a single space with an empty space next to it, or be centered in the layout to suit tastes. + +These cards contain the same information as the version on the previous page with three cards in a row. The only notable difference is that, with more space, the Transparency Log label and link can be gently sectioned off with a dotted line to maintain its association with the attestation while also occupying its own distinct space. + +By having two (or three, depending on page width) cards horizontally, with others stacked below, we can introduce more supporting information near the attestation box. The Integrity card should contain the "checksum" used to verify the attestation, along with a link to documentation to inform and educate users. Checksums are explored in more detail in this style guide. + +The possible and likely scenario of checksums being duplicated across page information is also addressed in the large medium UI mockups. In short, duplication was not an issue for users across any links or information. In fact, repeating details—such as links or checksum details, when they are supposed to match—was seen as a positive. All users we tested with reported greater confidence in the validity of the entire page’s information as a result. + +![A screenshot of a UI example of the medium level AA requirements for visualising attestation information with larger 'box' size](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/medium-requirements-3.png "A screenshot of a UI example of the medium level AA requirements for visualising attestation information with larger 'box' size") + +An example of the larger card sizes when a page width allows for three cards in a row with an additional Integrity card stacked under them in a row by itself. + +This indicates to the users that there could be more future information added here that is relevant to attestations. The design and layout did not look like there was 'unused space' to users but when implementing caution should be used when allowing for many solo/one cards as the information looks 'orphaned' when only one card is present and it does not attempt to span the width of the page layout's available space. + +![A screenshot of a UI example of the medium level AA requirements for visualising attestation information with larger 'box' size](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/medium-requirements-4.png "A screenshot of a UI example of the medium level AA requirements for visualising attestation information with larger 'box' size") + +An example—if appropriate and if sufficient page width is available—is centering a smaller row of cards beneath a larger row, as seen here with three cards in the first row and two cards in the second row, rather than either left or right aligning the smaller row. (The example shown uses two of the same attestation and is only intended to demonstrate display orientation.) + +![A screenshot of where the medium level AA UI should ideally be situated on a webpage](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/medium-requirements-webpage-placement-1.png "A screenshot of where the medium level AA UI should ideally be situated on a webpage") + +The positioning for the medium level AA UI are the same as the lowest level A UI. + +After critical functional information about what the package does and as near to the 'social proof' information as possible aka download numbers, maintainer/contributor profiles/names and other package provenance information. + +There was another tested Medium UI component that we've documented for clarity but no longer recommend implementing. This design follows in the next pages of medium requirements. + +![A screenshot of the medium level AA UI that uses a large, segmented container box for all information](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/medium-box-requirements-1.png "A screenshot of the medium level AA UI that uses a large, segmented container box for all information") + +When testing this large card's design, we learned that every user coming to a package registry page has some level of caution and/or doubt about the information it contains. They already arrive cautious and with shaky trust levels. This is due to thoughts like, “Anyone can just put any text or info on these pages, right? The maintainers or the registry, anyone? So by default, I don’t trust information unless I look at the sources and confirm for myself.” + +This means that “( ! ) caution...” messages—while they reinforce users’ existing caution and clarify risks—are often bothersome and typically unhelpful beyond a single, simple warning that reminds users to be careful. We recommend reducing the number of warning and caution-type messages across the page. + +This variant of the card component maintains a distinct design for the registries and platforms that would like these details to look like a clearly seperate component that is different (external) from regular page information. The colors and brand design elements can be styled per platform. + +This version also emphasizes explanatory text and warnings about the limitations of attestations—specifically, what an attestation is versus how the information presented might be interpreted by a user. + +Regarding language: this is the minimal design with the most clarifying text. For platforms that want to include as much disclaimer-like text as possible, this design (or the highest level, AAA, described later in this style guide) is recommended. + +![A screenshot of the medium level AA UI that uses a large, segmented container box for all information with annotation](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/medium-box-requirements-2.png "A screenshot of the medium level AA UI that uses a large, segmented container box for all information with annotation") + +A note on the words “verification,” “verified,” and “verify” versus using similar words like “confirm,” “confirmed,” “accepted,” “accepts,” “validates,” “inspected,” etc. + +When we asked users to explain back to us what attestation language meant to them, in our user tested designs, we avoided using "verified" as a term. Instead we relied on the terms "confirmed" or "accepted" as common language. + +Some users who lacked experience with attestation nuances explained this information as 'verification of complete safety of the package'. +When we clarified that verification of complete safety is aspirational--not nessesarily what is on offer here--users acknowledged that they understand no package is ever 100% safe, regardless of the details provided. + +However, this highlights the need to use terms like “verification” and “verified” with caution, as users often interpret them as a guarantee of complete safety. + +The language used in the card here—such as “confirms,” “accepts,” etc.—still clearly explains to users what is happening: that entities are checking details and asserting an opinionated “clearance” of certain aspects, such as build provenance or expected origin. However, users often jump to “verified!” assumptions. The term “verification” should only be used when a platform is prepared to accept the risk of users assuming full safety of a package when this word is present. + +![A screenshot of the medium level AA UI that uses a large, segmented container box with PyPI colours](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/medium-box-requirements-3.png "A screenshot of the medium level AA UI that uses a large, segmented container box with PyPI colours") + +Medium design that users least prefered. + +We mixed up all designs when showing users the UI. Users received Highest first, Lowest first and Medium first. This design tested the least favourably with users and therefore we're removing from the recommendation but retaining as documentation in the style guide to ensure clarity. + +This card attempts to combine all of the most useful information tested in the more minimal light and medium versions. Short of the AAA requirements, we consider this to be the most comprehensive version of the component which introduces new pages or sections to registries and platforms. This design aims to show all of the most relevant and relational information, including the specific, essential attestation data. You could liken it to having the “nutrition label” right next to the food name. + +Please open the following annotated UI full webpage examples in an image viewer of your choice. This image is large at 4.6MB and 14052x14542 pixel canvas. There is also a .pdf file. + +[https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/ui-development-medium-ui-version-a-level.png](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/ui-development-medium-ui-version-a-level.png) + +[https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/ui-development-medium-ui-version-a-level.pdf](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/ui-development-medium-ui-version-a-level.pdf) + +The following text is included in the annotated image file: + +An example of a row of equally sized cards that fits in the width of the main page section. + +Note in this example, there is no checksum/SHA container included in the design. + +Example of a two x two horizontal stacking of cards. In this example, the Integrity section includes checksum/SHA information, which helps visually balance the design. + +Platforms can choose to make a single container span two spaces. There is no strict rule for how wide or tall box containers should be, but it is strongly advised not to have containers of different heights next to each other (see diagram below). + +![A screenshot of the medium level AA UI showing good and bad placement](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/medium-ui-placement.png "A screenshot of the medium level AA UI showing good and bad placement") + +Note: the cards can either span the full width of the available page space, or they can occupy only the minimum width necessary for accessible visibility of information. + +Example of a single card stacked below three standard card. These three horizontal cards also occupy the minimum width space for available information. + diff --git a/attestations-ui-2025/4-Style guide_ Level AAA - Highest requirements - 1.pdf b/attestations-ui-2025/4-Style guide_ Level AAA - Highest requirements - 1.pdf new file mode 100644 index 0000000..e22722b Binary files /dev/null and b/attestations-ui-2025/4-Style guide_ Level AAA - Highest requirements - 1.pdf differ diff --git a/attestations-ui-2025/4-style-guide-level-aaa-highest-requiremments.md b/attestations-ui-2025/4-style-guide-level-aaa-highest-requiremments.md new file mode 100644 index 0000000..c41ad3f --- /dev/null +++ b/attestations-ui-2025/4-style-guide-level-aaa-highest-requiremments.md @@ -0,0 +1,120 @@ +# Style guide: Level AAA - Highest requirements + +The highest level of UI recommendations includes adding attestation information and/or links in an available sidebar section of a registry site or platform as well as a new security page, tab or section (depending on the platform architechture). The sidebar content can link to this security content when interacted with by users seeking more detailed information. + +## Security page section + +Having a separate, dedicated security section or page was the UI design that tested best across all user personas. Security Experts, Pragmatic Developers, and Incidental Users all found that a dedicated security page was the best place to locate the information they expected when looking for “information that helps them make a secure and safe choice about the packages they use.” This included attestation information. + +Users admitted that, during their typical workflows, the security section is not their first stop when gathering information; instead, they usually begin with the general package description, source repository links, and social proof metrics. However, the security section became easily recognizable once they were ready to review security and safety-related information. This meant users were not left guessing whether they were in the right place for security details about a package or build. When such information was placed on the main registry or platform pages, users had to do extra cognitive work to determine what attestations and related data meant in that context. They spent critical seconds scanning attestation statements and asking themselves, “Where am I, and what is this information in relation to exactly?” Within a dedicated security page or section, that effort was eliminated. + +Several users also noted that having a security page gave them the impression that the registry/platform and package were “serious and committed” to security. It also allowed for additional information to be included, in case more security details or advice needed to be added in the future. + +Some registries and platforms will not have pages or tabs where a dedicated security page can be added. In these cases, as with the example of the RubyGems package below, adding a security section beneath other sections is sufficient to set it apart and provide a link from sidebar content. Further details are provided in subsequent sections about how security page sections were tested and user rationale. + +![A screenshot of a UI example of the highest level AAA requirements for visualising attestation information along with entire security page content example](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/highest-requirements-1.png "A screenshot of a UI example of the highest level AAA requirements for visualising attestation information along with entire security page content example") + +With registries or platforms like PyPI that have a left-hand menu, the security page can be added there. + +PyPI is a complex example, as there is a lot of different information that users in testing considered to be "security" information that could be included in this section. The best advice is that platforms should make informed decisions about what existing information moves to the security page and what information should be linked from the security page. + +![A screenshot of a UI example of the highest level AAA requirements for visualising attestation information along with entire security page content example](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/highest-requirements-menu-2.png "A screenshot of a UI example of the highest level AAA requirements for visualising attestation information along with entire security page content example") + +![A screenshot of a UI example of the highest level AAA requirements for visualising attestation information along with entire security page content example](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/highest-requirements-2.png "A screenshot of a UI example of the highest level AAA requirements for visualising attestation information along with entire security page content example") + + +With registries or platforms like npm that have a navigation tab bar, the security page can be added there. + +In the npm examples we tested, the packages often displayed entire READMEs, which meant many pages of scrolling to find any information not included in the README. In some cases, users were confused about which information was written by package maintainers and which was provided by the registry. One suggestion that was offered, but not explored in the UI, was to add author names to content, including the publish date. For example: “This security page was last updated on [ DATE ] by npm to include [ DETAILS ].” + +![A screenshot of a UI example of the highest level AAA requirements for visualising attestation information along with entire security page content example](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/highest-requirements-menu-3.png "A screenshot of a UI example of the highest level AAA requirements for visualising attestation information along with entire security page content example") + +![A screenshot of a UI example of the highest level AAA requirements for visualising attestation information along with entire security page content example](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/highest-requirements-3.png "A screenshot of a UI example of the highest level AAA requirements for visualising attestation information along with entire security page content example") + +**Sidebar - Minimal** +If present on a page, the sidebar typically already contains critically useful information to help users decide whether or not to use a package and/or if a package is safe. This is usually where downloads, releases, source code or repository links, and contributors are listed. These pieces of information are important not just for safety and security, but are generally useful for users when exploring packages. + +The sidebar also became the primary location where users wanted to see attestation information. However, users indicated that they did not want attestation or security content to push down the other important information. They were also unlikely to read detailed or lengthy text content in sidebars. + +A minimal sidebar should therefore only be used in conjunction with a dedicated security page or section, with sidebar links functioning like "bookmarks" for the related security information on the page, directing or focusing the user on the relevant section when clicked (e.g., when the sidebar "Build confirmed" is clicked, it should focus on the "Build confirmed" section in the security page). In rare cases, components styled to meet Level AA requirements can be used optionally here in the UI alongside the minimal sidebar. + +**Sidebar - Maximum** +The maximum sidebar is a UI designed for users who are unlikely to explore the security page and do not want to dive deeply into security information or be redirected there by a link in the sidebar. These users are relatively rare, as the general expectation for sidebars is to contain only a few words of text (certainly not full sentences). However, there are scenarios where registries or platforms may want to display as much information in the sidebar as possible, or include some of the content from the security page as well. + +See below dedicated security sections, nav bar tabs and left hand menu tabs. We tested the term 'security' with and without the lock icon and it was preferred with the lock icon as so to reenforce user understanding of what this section does. It was not confused with a 'locked' section. + +There may be cases where the visual style of a registry or platform does not allow for icon usage. It is acceptable to omit the lock icon in these cases. + +![A screenshot of a UI example of the highest level AAA requirements for visualising the sidbar content specifcally](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/highest-requirements-4.png "A screenshot of a UI example of the highest level AAA requirements for visualising the sidbar content specifcally") + +As previously stated, when positioning attestation content in the sidebar, it should not appear above essential general information such as: + +• Source code repository links +• Homepages/URLs (if applicable) +• Releases +• License +• Download numbers (weekly, etc.) +• Version number +• File size +• Last published date +• Maintainer/Contributor profile pictures and/or names + +Typically, this means that attestation information will still appear within the first scroll of the sidebar. Ideally, it should be placed as high as possible without displacing essential information. + +We tested some expandable sections in the sidebar, but these did not perform well with users. There is a general expectation that sidebar information should be presented as is, or take you to an internal or external link, rather than expanding or contracting within the sidebar. + +![A screenshot of the highest level AAA UI showing good and bad placement](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/highest-requirements-webpage-placement-1.png "A screenshot of the highest level AAA UI showing good and bad placement") + +Please open the following annotated UI full webpage examples in an image viewer of your choice. This image is large at 3.2MB and 10982x5000 pixel canvas. There is also a .pdf file. + +[https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/ui-development-highest-ui-version-a-level.png](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/ui-development-highest-ui-version-a-level.png) + +[https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/ui-development-highest-ui-version-a-level.pdf](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/ui-development-highest-ui-version-a-level.pdf) + +The following text is included in the annotated image file: + +These sidebar designs are the information-dense versions, where all relevant and helpful details to support attestation comprehension are surfaced. These sidebars can function on their own as a “light/medium” implementation or in combination with Level AA requirement card components, or as part of the Level AAA security page implementations described on this page. + +These sidebar designs were heavily informed by the fact that users we tested with found the most useful information in the sidebars already. The users prioritised "social web of transparency" information alongside the source code and repository links which are typically included in the sidebar of existing registry pages. However, like in main page content users did not want attestation information and supplementary info below these critical general pieces of information. This typically means the attestation information still appears above the fold, within the first scroll, for most pages. + +You can see that the information can look squeezed into a small width for sidebars like rubygems page layout. We recommend that the sidebar widths not be any narrower than this example, as writing sentence-length content in a smaller space would be difficult for developers to read and comprehend. + +These sidebar designs are the minimal information versions, reduced to the essentials: icon, heading, and links. + +Links in the minimal sidebar design must direct users to a dedicated security page for each package. This approach works especially well for pages that feature extensive README content or large amounts of package information. This allows the sidebar content to appear higher on the page, but not necessarily before the README, while components with additional detailed information can be placed after the README. + +The only information that is not minimized is the attestation statement (or a selected attestation statement if there are multiple on a package). This statement must always be shown in full, accompanied by its icon and a link to more detailed information in the security section. + +Security page for npm would be via a new tab 'security' +Security page for pypi would be via a new left tab 'security' +Security page for rubygems would be via a new main section header for rubygems in the main page + +Underneath the security heading you can see a short yet visually not overwhelming. This directs users immediately to more detailed documentation on gem security should the user immediately want to dive into the documentation. + +Because rubygems doesn't have seperate pages for some packages, including a new heading, below the last heading that reads 'Security' allows us to place the relevant security related information, along with the attestation information here. + +The layout here may looks familiar to the lowest and medium UI designs. This section does follow the same 'container box' UI in horizontal row numbers that make sense given the page width. + +Here it's essential that the attestation/s take up the full width of the page or occupies more width that the build, source and integrity in order to give visual priority to the attestation section. The reason we don't lead with the attestation section over the build, source or integrity is because those sections are more commonly known/understood whereas attestations are understood better in relation to those pieces of information, so leading with build, source and integrity, then attestations sets up the user for thinking about build security and who/how is verifiying that. + +The heading of build provenace was added when we found that users needed more context around what the attestation and supplementary info is trying to inform users of. This heading makes the meaning explicit. + +Similarly, there's a message under the attestation container box that further attempts to clarify what attestation information is meaning to inform users of. + +The integrity section contains any other existing information related to provenance or package security processes. This is where some information may now have duplicates in the page. + +As noted elsewhere in this styleguide duplicates are not a problem for users and give them more confidence in the package information as long as the duplicate information indeed matches when it is supposed to. + +The last section here is a security advisory section. This should be present if the platform has a way to pull in and display any reliably sourced advisories. If a platform has no access to a database of security advisories then this section should be omitted. + +The section is placed at the bottom due to in user testing users were very positively inclinced to this section. They were so positively responsive to this section they often stopped looking at any other information in order to check for security information about the package. Deprioritising this section and placing it low is to stop users from focussing solely on that section. + +Note that on each of these next designs the minimal information sidebars are also present. + +These sections on the side bar, when clicked should 'focus' and/or send the user to the appropriate section in the main page in the security section. + +Pypi has a secuirty tab in the menu + +Different platforms and registries have different detailed security information that can be brought into the security tab/pagees + +npm has a secuirty tab in the menu nav \ No newline at end of file diff --git a/attestations-ui-2025/5-Style guide_ Attestations UI in detail.pdf b/attestations-ui-2025/5-Style guide_ Attestations UI in detail.pdf new file mode 100644 index 0000000..d4d070f Binary files /dev/null and b/attestations-ui-2025/5-Style guide_ Attestations UI in detail.pdf differ diff --git a/attestations-ui-2025/5-style-guide-ui-details.md b/attestations-ui-2025/5-style-guide-ui-details.md new file mode 100644 index 0000000..1b69140 --- /dev/null +++ b/attestations-ui-2025/5-style-guide-ui-details.md @@ -0,0 +1,235 @@ +# Style guide: UI details + +## Style guide: Attestations component + +Overall, all of these attestation statements tested well. We recognize that they may not be 100% technically precise in expressing the objective language of an attestation. We user tested wording associated with authority—statements that “approve,” “verify,” “validate,” and/or “confirm” that everything related to the package build was as expected. + +The users we tested tended to either skim or read in detail. All of the users generally understood these types of statements and agreed they helped them believe the package was safer and more “official.” This was especially important for packages that lacked high download numbers or strong social/web-of-trust proof. + +Attestations became much more critical in the smaller, niche package scenarios users described. The users we tested also unanimously agreed that the icon was helpful in understanding an attestation. The attestation statements used in these UI mock ups may not be the most literal and accurate statements. We recommend technical writers to write the most accurate attesttation claim wording. + +If a registry/playtform wants to make attestations the most prominent they can, we recommend a UI with the full-width box container UI. + +![A screenshot of the UI Attestations component in isolation](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/attestations-component.png "A screenshot of the UI Attestations component in isolation") + +## Style guide: Build component + +The Build component were the most important relational information to attestations that users we tested expressed as useful. + +All users agreed that this information could be sourced from other locations or from the source repository itself, but having it near attestations made it quicker and easier to find and relate to the purpose of a build attestation statement. + +The links shown in the mock up may not be the exact ones that the packages would use for 'Build commit/file' and 'Build logs' but as long as these destinations are what folks with technical and package knowedge would place there then users are satisfied and go where they expect to go. In testing, we had the first link with the label 'Build commit'. We've since changed this label to 'Build workflow' to better describe the link used in the examples. + +Reviewing the build commit/file and logs is a process that not everyone—except security experts we tested—knew exactly how to approach or compare; and for those users, the existence of this information helped create an impression of safety, security, and legitimacy for the package page. Typically, users we tested matched the links provided in the Build or Build confirmed components with what they could find themselves in the source repository. + +All of the users expressed a desire for more documentation and guidance on how to assess build security. + +![A screenshot of the UI build component in isolation](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/build-component.png "A screenshot of the UI build component in isolation") + +## Style guide: Source component + +While users could find the source information elsewhere on the package's page, having the source repo link and source commit link in proximity to build information and the attestation again, mean't users found this information easily and in the context of attestation investigation/comprehension. + +To reiterate a user finding, users did not find duplicate information distracting, confusing or less-secure, they found the information useful when duplicated since they 'could either go there from here or here' it made their opening of relevant links and docs more convenient. + +Source was one location where there are two icon options, either the box to represent 'package' or the browser and code <> brackets to represent source code. + +![A screenshot of the UI source component in isolation](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/source-component.png "A screenshot of the UI source component in isolation") + +## Style guide: Integrity component + +The integrity section—where we display a checksum, SHA-256, or hash for the attestation—was an area that divided opinions among the internal design team. + +Users we tested generally found this section to be useful and/or interesting, depending on whether they already understood what a checksum did and how to use it. Those who did felt more confident in the security of the build, attestation, or package, and were happy to see a checksum included. Suprisingly, the users we tested were not bothered by possible duplication; in fact, duplication signaled importance (as long as the values matched when appropriate and were correct). + +Users who didn’t know what checksums were used for or how to use them were curious rather than confused. They sensed that the information was important and potentially useful, should they choose to invest time in learning what it was. These users only needed clear documentation or guidance links on how to use checksums, referenced near the checksum information. Again, they were not confused by potential duplication; instead, they interpreted as “this must be important”, an essential trust signal. + +The term “integrity” and the magnifying glass icon helped the users understand that something was being inspected and clarified what their suggested action—investigating further—should be. Yet, internally, we also believe that “Inspect” could be used instead of “Integrity,” as “integrity” may not accurately describe this information. + +![A screenshot of the UI integrity component in isolation](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/integrity-component.png "A screenshot of the UI integrity component in isolation") + +## Style guide: Additional signals of trust + +There were a few additional trust signals we tested with users that either were not included in the style guide recommendations, were minimized, or appeared only in the highest-level recommendations. This is mostly because these elements require additional work before they can be reliably implemented (e.g., Security Advisories), or they are not yet well-known terms or concepts and require their own detailed investigation and user research. + +The first element that tested well with security experts—but not with less informed developer users—was sections or badges referring to SBOM (Software Bill of Materials) and SLSA3 (Supply-chain Levels for Software Artifacts at hardened build level https://slsa.dev/spec/v1.1/levels). + +When known, these terms provided very positive security and safety signals for a package. When not known, some users chose to search or visit documentation to learn more, but the small components tested did not offer clear incentives as to why they should learn about these concepts or what benefits they provide. Therefore, these elements need comprehensive testing with appropriate guidance for users to seek and understand related documentation. + +![A screenshot of the UI for additional signals of trust](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/additional-signals-of-trust-1.png "A screenshot of the UI for additional signals of trust") + +Known security advisories were included in the highest level of UI recommendations for attestations. This component tested incredibly well—so well that users often ignored other information in favor of it. (This is covered in more detail in the highest-level UI requirements.) This component requires further user research to fully understand why it is so implicitly trusted over other information. + +When an attestation statement used the term “trusted publisher,” this was somewhat confusing for security expert users. Most users accepted the statement at face value and assumed the registry, platform, or another entity—such as GitHub—was taking accountability by using the label “trusted publisher.” Security experts we tested, however, wanted to know exactly who or what the trusted publisher is, and what they are attesting to. + +![A screenshot of the UI for additional signals of trust](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/additional-signals-of-trust-2.png "A screenshot of the UI for additional signals of trust") + +Step-by-step instructions for using checksums or SHA-256 were mentioned in very early user research as a way to help users with less security expertise become informed and follow the appropriate steps to process or verify SHA-256 checksums, hashes, or key signatures. The less security-proficient users indicated that if they didn’t already know what this was, they wouldn’t have time to learn the process while investigating packages. Instead, they would return to it after selecting a package or if given time in their job roles to learn or be shown how to do it. + +As the style guide was further developed, we found that these processes we'd enable with this component were lengthy, difficult to fit into minimal UI, and not as critical for attestations. + +A very early design for an expandable set of step by step instructions for checking hashes. + +![A screenshot of the UI for additional signals of trust](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/additional-signals-of-trust-3.png "A screenshot of the UI for additional signals of trust") + +## Style guide: Icons + +Icons became a critical aspect of the attestation work. Icons helped users we tested comprehend and understand what a section or heading was intended to convey, or prompted them to take a certain action or adopt a particular mindset. + +Some of our general findings on icons were: + +1. Initially, no users mentioned the icons. This typically suggests that none of the icons appeared odd, strange, or out of place wherever they were used. + +2. When users did mention icons, they typically praised them for matching the headings or statements they accompanied. + +3. Users generally preferred filled-in icons over stroke or outline icons, though each registry or platform should use icon styles that best fit their overall visual aesthetic. + +4. The only icon that should not be filled in and should always remain an outline is the blue information (i) icon (as shown in mock-ups). Users found a filled version of this icon more distracting and annoying than useful. However, retaining these info statements is critical for clarifying what an attestation can and cannot verify. + +5. One participant did not like the crane icon for “Build” and preferred the unfinished wall of bricks. The wall symbolizes the process of building something, whereas the crane appeared to represent moving a package from one location to another. However, overall, the crane tested better with users. + +6. The box icon symbolized a "package," while the browser and <> brackets icon symbolized "source code." + +7. The (!) warning icon should be used as sparingly as possible. Users tend to focus on this icon, which can reinforce existing feelings of distrust. Using the outlined version as well can help de-emphasize this icon. + +All icons were source from an open icons SVG repo: https://www.svgrepo.com/ + +Links to individual icons will follow. Two unique icons were created by combining two or more open icons: the integrity magnifying glass with key, and the attestation signature icon. These will be detailed on the following pages. + +![A screenshot of the UI for icons](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/icons-1.png "A screenshot of the UI for icons") + +Text included in the icons image: + +Re. Build icons: Use whichever you think matches your design style and if unsure - go with the crane. Brick icon was edited to remove small details +Re. Security icon: The lock icon was used for highest requirements pages next to the security heading/tab +Re. Warning & info icon: Advised to only use the outline/stroke versions of the ! and i icons. +Re. SLSA3 icon: Early designs used this recipet icon for SLSA3. +Re. SBOM icon: Early designs used this recipet icon for SBOM. +Re. Copy icon: Used where a copy function against a CLI command or hash was +Re. Links icon: Only used to mimic existing link icon styles in registry pages + +![A screenshot of the UI for signature icon](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/signature-icon.png "A screenshot of the UI for signature icon") + +The signature icon was a critical icon to construct and took detailed editing of existing icons to balance the width and height of a signature, pen and container and/or the 'box or 'line' that people sign on a paper document. +User all agreed this icon helped them to get an idea of what an attestation and references to 'signatures' mean't within the context. That some entity is 'signing off' in some way to the statement being made in the attestation statment. + +![A screenshot of the UI for icons](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/icons-2.png "A screenshot of the UI for icons") + +Text included in the icons image: + +Re. Source icon: Source icon was used as is from the open source icon repo. Users described needing this icon after seeing the package used for 'source' +Re. Integrity icon: The integrity magnifying glass was created by combining two icons. Users described the key in the magnifying glass as being critical to communicate 'investigating the security'. The term 'Integrity' also helped users understand that the information with this icon and heading was there to help them 'seek information related to security' +Re. Package icon: The package icon was an edited version of some complex boxes from the icon repo. This box accurately communicated package to all users where it was used. They expected to see package info like source repo and package ino like version, name etc. + +![A screenshot of the UI development for an attestation specific icon](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/attestation-icon-development.png "A screenshot of the UI development for an attestation specific icon") + +Early on some design work was done to try to reduce the attestation UI down to a single icon or badge. After some effort it was decided that for most users that are not security experts a badge or icon without any messaging wouldn't be useful. The only user person that a badge/icon is useful for are people who are alreayd well informed about attestations and begin to associate that knowledge with whatever badge/icon was cerated. There was no simple way to reduce these concepts into a symbol. It is worth re-exploring with a graphic desing, icon or other expert in brand/indentity language what can be created but for now, the progress made on attestation badge/icons is below. + +Some of our early designs attempted to 'tell the story' of attestations from 'origin' to signed attestation statement on a package. We developed visual styles that used a mail/postal package being delivered and signed. This story /inforgraphic visual has potential but within registry pages for UI it was too complicated and required a user to swap to info gathering to story comprehension mode. Infographics could be good for documentation pages and should be tested. + +https://www.svgrepo.com/svg/446714/magnifying-glass-2 +https://www.svgrepo.com/svg/437226/signature +https://www.svgrepo.com/svg/212549/signature +https://www.svgrepo.com/svg/509138/info +https://www.svgrepo.com/svg/532318/key +https://www.svgrepo.com/svg/521262/warning-circle +https://www.svgrepo.com/svg/449387/lock +https://www.svgrepo.com/svg/355633/bill-1-solid +https://www.svgrepo.com/svg/325456/open-in-window +https://www.svgrepo.com/svg/471214/code-browser +https://www.svgrepo.com/svg/471736/package-check +https://www.svgrepo.com/svg/525265/check-circle +https://www.svgrepo.com/svg/510388/copy +https://www.svgrepo.com/svg/523501/link +https://www.svgrepo.com/svg/426115/crane +https://www.svgrepo.com/svg/414268/build + + +Icons are licensed under different OSS licenses. Some require attribution. + +https://www.svgrepo.com/page/licensing/#CC%20Attribution + + +## Style guide: Hyperlinks + +User behavior and attitudes towards hyperlinks were nuanced, especially when balancing user preferences with the limited space available in components. + +We found two details are critical with hyperlink usage: + +1. If space constraints prevent displaying the full URL, ensure the complete URL is shown on hover (by mouse or tab). + +2. Each link’s descriptive text should clearly indicate the link’s destination or purpose, avoiding vague labels (e.g., use the text “See steps to complete process a checksum hash >” instead of “Learn more >”) + +Examples: +Any of the following variations of hyperlinks can be used; yet, their styling should always be accessible and consistent with the global styles for other hyperlinks across the platform. + +1. Label with a full URL where space allows: +Transparency log: https://search.sigstore.dev/?logIndex=304840876 + +2. Label with a ellipsis truncated URL, provides full disclosure on hover: +Transparency log: https://search.sigstore.dev/?lo... + +3. Label with a shortened URL: +Transparency log: search.sigstore.dev/?logIndex=304840876 + +4. Descriptive phrase with hyperlink styling: +View transparency log > + +Styling for hyperlinks should also follow the same style as other links across the platform. + +![A screenshot of the UI development for hyperlinks](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/hyperlinks.png "A screenshot of the UI development for hyperlinks") + +## Style guide: A note on right to left languages + +All designs were created for package registries using left-to-right, English-language characters. We did not have scope to explore languages with longer words, such as German, or languages that are read right-to-left, such as Arabic. + +Should work continue on this project or similar content, translations into languages other than English should be done and tested. Additionally, designs should be evaluated for tab navigation, screen-reader compatibility, and accessibility tools such as eye-gaze trackers, which may require larger hit areas for selection. + +We also recommend testing iconography to ensure that no icons convey unintended meanings in cultures beyond the assumed Western, US/European, English-speaking context. + +![A screenshot of right to left languages](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/japanese.png "A screenshot of right to left languages") + +Japanese is an example of 'signature' or サイン being a more modern word but many Japanese people still use a 'stamp' (印鑑) as their signature. + +![A screenshot of right to left languages](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/arabic.png "A screenshot of right to left languages") + +Arabic needs to have all elements viewed right to left. + +![A screenshot of right to left languages](https://github.com/ossf/wg-securing-software-repos/tree/main/attestations-ui-2025/images/german.png "A screenshot of right to left languages") + +German is also a useful example as it often has words that in English are two words 'Transparency log' and in German are one word 'Transparenzprotokoll' + +## Style guide: Documentation recommendations + +Supporting users with effective documentation is key to helping them build an understanding of what attestations are and how they can be used. + +Our research found that existing documentation about attestations was either missing entirely or written only for expert audiences. To address this and to support our UI recommendations, we suggest the following principles to help registries create effective documentation for attestation consumers. + +Attestations documentation principles + +1. Use key terms consistently +2. Structure documentation around user roles +3. Provide content to help package consumers understand attestations within the + context of other security features +4. Warn package consumers that packages are not secure by default +5. Normalize secure-by-default publishing workflows +6. Explain common attacks and how they are mitigated +7. Be transparent about limitations and set clear expectations + +For more information on each principle see Best practices for documenting attestations in Package Repositories: +https://github.com/user-attachments/files/21981715/best_practices_for_documenting_attestations_in_package_repositories.pdf + +## Style guide: Applying documentation principles to RubyGems.org, PyPI and npm + +To help RubyGems.org, PyPI, and npm adopt attestation documentation best practices, we have created specific recommendations for each repository. Each recommendation includes user-tested templates that can be used to create new documentation or revise existing materials. + +We encourage RubyGems.org, PyPI and npm to use, improve, and extend these templates as they see fit. Other package repositories can also use these templates as inspiration for their own attestations documentation. + +RubyGems.org documentation recommendations +https://github.com/user-attachments/files/21981846/rubygems_attestation_documentation_templates.zip + +PyPI documentation recommendations +https://github.com/user-attachments/files/21981898/pypi_attestation_documentation_templates.zip + +npm documentation recommendations +https://github.com/user-attachments/files/21994138/npm_attestation_documentation_templates.zip diff --git a/attestations-ui-2025/UI for Attestations - Style guide.penpot b/attestations-ui-2025/UI for Attestations - Style guide.penpot new file mode 100644 index 0000000..737dec1 Binary files /dev/null and b/attestations-ui-2025/UI for Attestations - Style guide.penpot differ diff --git a/attestations-ui-2025/1-attestations-style-guide-intro-and-background.pdf b/attestations-ui-2025/Version 1 - depreciated/1-attestations-style-guide-intro-and-background.pdf similarity index 100% rename from attestations-ui-2025/1-attestations-style-guide-intro-and-background.pdf rename to attestations-ui-2025/Version 1 - depreciated/1-attestations-style-guide-intro-and-background.pdf diff --git a/attestations-ui-2025/2-style-guide-level-a-lowest-requirements.pdf b/attestations-ui-2025/Version 1 - depreciated/2-style-guide-level-a-lowest-requirements.pdf similarity index 100% rename from attestations-ui-2025/2-style-guide-level-a-lowest-requirements.pdf rename to attestations-ui-2025/Version 1 - depreciated/2-style-guide-level-a-lowest-requirements.pdf diff --git a/attestations-ui-2025/3-ui-development-lowest-minimal-ui-version-a-level.pdf b/attestations-ui-2025/Version 1 - depreciated/3-ui-development-lowest-minimal-ui-version-a-level.pdf similarity index 100% rename from attestations-ui-2025/3-ui-development-lowest-minimal-ui-version-a-level.pdf rename to attestations-ui-2025/Version 1 - depreciated/3-ui-development-lowest-minimal-ui-version-a-level.pdf diff --git a/attestations-ui-2025/4-style-guide-level-aa-medium-requirements.pdf b/attestations-ui-2025/Version 1 - depreciated/4-style-guide-level-aa-medium-requirements.pdf similarity index 100% rename from attestations-ui-2025/4-style-guide-level-aa-medium-requirements.pdf rename to attestations-ui-2025/Version 1 - depreciated/4-style-guide-level-aa-medium-requirements.pdf diff --git a/attestations-ui-2025/5-ui-development-medium-ui-version-aa-grade.pdf b/attestations-ui-2025/Version 1 - depreciated/5-ui-development-medium-ui-version-aa-grade.pdf similarity index 100% rename from attestations-ui-2025/5-ui-development-medium-ui-version-aa-grade.pdf rename to attestations-ui-2025/Version 1 - depreciated/5-ui-development-medium-ui-version-aa-grade.pdf diff --git a/attestations-ui-2025/6-style-guide-level-aaa-highest-requirements.pdf b/attestations-ui-2025/Version 1 - depreciated/6-style-guide-level-aaa-highest-requirements.pdf similarity index 100% rename from attestations-ui-2025/6-style-guide-level-aaa-highest-requirements.pdf rename to attestations-ui-2025/Version 1 - depreciated/6-style-guide-level-aaa-highest-requirements.pdf diff --git a/attestations-ui-2025/7-side-bar-designs-more-info-and-less-info-with-security-page.pdf b/attestations-ui-2025/Version 1 - depreciated/7-side-bar-designs-more-info-and-less-info-with-security-page.pdf similarity index 100% rename from attestations-ui-2025/7-side-bar-designs-more-info-and-less-info-with-security-page.pdf rename to attestations-ui-2025/Version 1 - depreciated/7-side-bar-designs-more-info-and-less-info-with-security-page.pdf diff --git a/attestations-ui-2025/8-style-guide-attestations-ui-in-detail.pdf b/attestations-ui-2025/Version 1 - depreciated/8-style-guide-attestations-ui-in-detail.pdf similarity index 100% rename from attestations-ui-2025/8-style-guide-attestations-ui-in-detail.pdf rename to attestations-ui-2025/Version 1 - depreciated/8-style-guide-attestations-ui-in-detail.pdf diff --git a/attestations-ui-2025/UI for Attestations - Style guide-aug-30-2025.penpot b/attestations-ui-2025/Version 1 - depreciated/UI for Attestations - Style guide-aug-30-2025.penpot similarity index 100% rename from attestations-ui-2025/UI for Attestations - Style guide-aug-30-2025.penpot rename to attestations-ui-2025/Version 1 - depreciated/UI for Attestations - Style guide-aug-30-2025.penpot diff --git a/attestations-ui-2025/images/.DS_Store b/attestations-ui-2025/images/.DS_Store new file mode 100644 index 0000000..da85257 Binary files /dev/null and b/attestations-ui-2025/images/.DS_Store differ diff --git a/attestations-ui-2025/images/additional-signals-of-trust-1.png b/attestations-ui-2025/images/additional-signals-of-trust-1.png new file mode 100644 index 0000000..39f5d4f Binary files /dev/null and b/attestations-ui-2025/images/additional-signals-of-trust-1.png differ diff --git a/attestations-ui-2025/images/additional-signals-of-trust-2.png b/attestations-ui-2025/images/additional-signals-of-trust-2.png new file mode 100644 index 0000000..ca8009e Binary files /dev/null and b/attestations-ui-2025/images/additional-signals-of-trust-2.png differ diff --git a/attestations-ui-2025/images/additional-signals-of-trust-3.png b/attestations-ui-2025/images/additional-signals-of-trust-3.png new file mode 100644 index 0000000..c636733 Binary files /dev/null and b/attestations-ui-2025/images/additional-signals-of-trust-3.png differ diff --git a/attestations-ui-2025/images/arabic.png b/attestations-ui-2025/images/arabic.png new file mode 100644 index 0000000..df481f5 Binary files /dev/null and b/attestations-ui-2025/images/arabic.png differ diff --git a/attestations-ui-2025/images/attestation-icon-development.png b/attestations-ui-2025/images/attestation-icon-development.png new file mode 100644 index 0000000..f64d81d Binary files /dev/null and b/attestations-ui-2025/images/attestation-icon-development.png differ diff --git a/attestations-ui-2025/images/attestations-component.png b/attestations-ui-2025/images/attestations-component.png new file mode 100644 index 0000000..0a8c739 Binary files /dev/null and b/attestations-ui-2025/images/attestations-component.png differ diff --git a/attestations-ui-2025/images/build-component.png b/attestations-ui-2025/images/build-component.png new file mode 100644 index 0000000..1ceb55b Binary files /dev/null and b/attestations-ui-2025/images/build-component.png differ diff --git a/attestations-ui-2025/images/german.png b/attestations-ui-2025/images/german.png new file mode 100644 index 0000000..423a03e Binary files /dev/null and b/attestations-ui-2025/images/german.png differ diff --git a/attestations-ui-2025/images/highest-requirements-1.png b/attestations-ui-2025/images/highest-requirements-1.png new file mode 100644 index 0000000..08e0559 Binary files /dev/null and b/attestations-ui-2025/images/highest-requirements-1.png differ diff --git a/attestations-ui-2025/images/highest-requirements-2.png b/attestations-ui-2025/images/highest-requirements-2.png new file mode 100644 index 0000000..f470b3f Binary files /dev/null and b/attestations-ui-2025/images/highest-requirements-2.png differ diff --git a/attestations-ui-2025/images/highest-requirements-3.png b/attestations-ui-2025/images/highest-requirements-3.png new file mode 100644 index 0000000..5b2e0de Binary files /dev/null and b/attestations-ui-2025/images/highest-requirements-3.png differ diff --git a/attestations-ui-2025/images/highest-requirements-4.png b/attestations-ui-2025/images/highest-requirements-4.png new file mode 100644 index 0000000..589944f Binary files /dev/null and b/attestations-ui-2025/images/highest-requirements-4.png differ diff --git a/attestations-ui-2025/images/highest-requirements-menu-2.png b/attestations-ui-2025/images/highest-requirements-menu-2.png new file mode 100644 index 0000000..f9855ab Binary files /dev/null and b/attestations-ui-2025/images/highest-requirements-menu-2.png differ diff --git a/attestations-ui-2025/images/highest-requirements-menu-3.png b/attestations-ui-2025/images/highest-requirements-menu-3.png new file mode 100644 index 0000000..8b53f83 Binary files /dev/null and b/attestations-ui-2025/images/highest-requirements-menu-3.png differ diff --git a/attestations-ui-2025/images/highest-requirements-webpage-placement-1.png b/attestations-ui-2025/images/highest-requirements-webpage-placement-1.png new file mode 100644 index 0000000..66019d4 Binary files /dev/null and b/attestations-ui-2025/images/highest-requirements-webpage-placement-1.png differ diff --git a/attestations-ui-2025/images/hyperlinks.png b/attestations-ui-2025/images/hyperlinks.png new file mode 100644 index 0000000..9144f0d Binary files /dev/null and b/attestations-ui-2025/images/hyperlinks.png differ diff --git a/attestations-ui-2025/images/icons-1.png b/attestations-ui-2025/images/icons-1.png new file mode 100644 index 0000000..9a1c0ad Binary files /dev/null and b/attestations-ui-2025/images/icons-1.png differ diff --git a/attestations-ui-2025/images/icons-2.png b/attestations-ui-2025/images/icons-2.png new file mode 100644 index 0000000..b31ea28 Binary files /dev/null and b/attestations-ui-2025/images/icons-2.png differ diff --git a/attestations-ui-2025/images/integrity-component.png b/attestations-ui-2025/images/integrity-component.png new file mode 100644 index 0000000..abf44a6 Binary files /dev/null and b/attestations-ui-2025/images/integrity-component.png differ diff --git a/attestations-ui-2025/images/japanese.png b/attestations-ui-2025/images/japanese.png new file mode 100644 index 0000000..ad5a35d Binary files /dev/null and b/attestations-ui-2025/images/japanese.png differ diff --git a/attestations-ui-2025/images/lowest-requirements-1.png b/attestations-ui-2025/images/lowest-requirements-1.png new file mode 100644 index 0000000..f357768 Binary files /dev/null and b/attestations-ui-2025/images/lowest-requirements-1.png differ diff --git a/attestations-ui-2025/images/lowest-requirements-2.png b/attestations-ui-2025/images/lowest-requirements-2.png new file mode 100644 index 0000000..ddd6563 Binary files /dev/null and b/attestations-ui-2025/images/lowest-requirements-2.png differ diff --git a/attestations-ui-2025/images/lowest-requirements-3.png b/attestations-ui-2025/images/lowest-requirements-3.png new file mode 100644 index 0000000..018b09b Binary files /dev/null and b/attestations-ui-2025/images/lowest-requirements-3.png differ diff --git a/attestations-ui-2025/images/lowest-requirements-4.png b/attestations-ui-2025/images/lowest-requirements-4.png new file mode 100644 index 0000000..36c80d0 Binary files /dev/null and b/attestations-ui-2025/images/lowest-requirements-4.png differ diff --git a/attestations-ui-2025/images/lowest-requirements-5.png b/attestations-ui-2025/images/lowest-requirements-5.png new file mode 100644 index 0000000..484a35e Binary files /dev/null and b/attestations-ui-2025/images/lowest-requirements-5.png differ diff --git a/attestations-ui-2025/images/lowest-requirements-webpage-placement-1.png b/attestations-ui-2025/images/lowest-requirements-webpage-placement-1.png new file mode 100644 index 0000000..671d2fa Binary files /dev/null and b/attestations-ui-2025/images/lowest-requirements-webpage-placement-1.png differ diff --git a/attestations-ui-2025/images/medium-box-requirements-1.png b/attestations-ui-2025/images/medium-box-requirements-1.png new file mode 100644 index 0000000..fb9cb3b Binary files /dev/null and b/attestations-ui-2025/images/medium-box-requirements-1.png differ diff --git a/attestations-ui-2025/images/medium-box-requirements-2.png b/attestations-ui-2025/images/medium-box-requirements-2.png new file mode 100644 index 0000000..cda6475 Binary files /dev/null and b/attestations-ui-2025/images/medium-box-requirements-2.png differ diff --git a/attestations-ui-2025/images/medium-box-requirements-3.png b/attestations-ui-2025/images/medium-box-requirements-3.png new file mode 100644 index 0000000..c92ae43 Binary files /dev/null and b/attestations-ui-2025/images/medium-box-requirements-3.png differ diff --git a/attestations-ui-2025/images/medium-requirements-1.png b/attestations-ui-2025/images/medium-requirements-1.png new file mode 100644 index 0000000..345bbd7 Binary files /dev/null and b/attestations-ui-2025/images/medium-requirements-1.png differ diff --git a/attestations-ui-2025/images/medium-requirements-2.png b/attestations-ui-2025/images/medium-requirements-2.png new file mode 100644 index 0000000..745222a Binary files /dev/null and b/attestations-ui-2025/images/medium-requirements-2.png differ diff --git a/attestations-ui-2025/images/medium-requirements-3.png b/attestations-ui-2025/images/medium-requirements-3.png new file mode 100644 index 0000000..4fe1d6a Binary files /dev/null and b/attestations-ui-2025/images/medium-requirements-3.png differ diff --git a/attestations-ui-2025/images/medium-requirements-4.png b/attestations-ui-2025/images/medium-requirements-4.png new file mode 100644 index 0000000..3801293 Binary files /dev/null and b/attestations-ui-2025/images/medium-requirements-4.png differ diff --git a/attestations-ui-2025/images/medium-requirements-webpage-placement-1.png b/attestations-ui-2025/images/medium-requirements-webpage-placement-1.png new file mode 100644 index 0000000..5cece52 Binary files /dev/null and b/attestations-ui-2025/images/medium-requirements-webpage-placement-1.png differ diff --git a/attestations-ui-2025/images/medium-ui-placement.png b/attestations-ui-2025/images/medium-ui-placement.png new file mode 100644 index 0000000..45c5df0 Binary files /dev/null and b/attestations-ui-2025/images/medium-ui-placement.png differ diff --git a/attestations-ui-2025/images/research-synthesis.png b/attestations-ui-2025/images/research-synthesis.png new file mode 100644 index 0000000..fdbbf19 Binary files /dev/null and b/attestations-ui-2025/images/research-synthesis.png differ diff --git a/attestations-ui-2025/images/signature-icon.png b/attestations-ui-2025/images/signature-icon.png new file mode 100644 index 0000000..1d17b3f Binary files /dev/null and b/attestations-ui-2025/images/signature-icon.png differ diff --git a/attestations-ui-2025/images/source-component.png b/attestations-ui-2025/images/source-component.png new file mode 100644 index 0000000..f396af1 Binary files /dev/null and b/attestations-ui-2025/images/source-component.png differ diff --git a/attestations-ui-2025/images/ui-development-highest-ui-version-a-level.pdf b/attestations-ui-2025/images/ui-development-highest-ui-version-a-level.pdf new file mode 100644 index 0000000..ced50c1 Binary files /dev/null and b/attestations-ui-2025/images/ui-development-highest-ui-version-a-level.pdf differ diff --git a/attestations-ui-2025/images/ui-development-highest-ui-version-a-level.png b/attestations-ui-2025/images/ui-development-highest-ui-version-a-level.png new file mode 100644 index 0000000..4f618bf Binary files /dev/null and b/attestations-ui-2025/images/ui-development-highest-ui-version-a-level.png differ diff --git a/attestations-ui-2025/images/ui-development-lowest-ui-version-a-level.pdf b/attestations-ui-2025/images/ui-development-lowest-ui-version-a-level.pdf new file mode 100644 index 0000000..a59e545 Binary files /dev/null and b/attestations-ui-2025/images/ui-development-lowest-ui-version-a-level.pdf differ diff --git a/attestations-ui-2025/images/ui-development-lowest-ui-version-a-level.png b/attestations-ui-2025/images/ui-development-lowest-ui-version-a-level.png new file mode 100644 index 0000000..195e1dc Binary files /dev/null and b/attestations-ui-2025/images/ui-development-lowest-ui-version-a-level.png differ diff --git a/attestations-ui-2025/images/ui-development-medium-ui-version-a-level.pdf b/attestations-ui-2025/images/ui-development-medium-ui-version-a-level.pdf new file mode 100644 index 0000000..837b4fc Binary files /dev/null and b/attestations-ui-2025/images/ui-development-medium-ui-version-a-level.pdf differ diff --git a/attestations-ui-2025/images/ui-development-medium-ui-version-a-level.png b/attestations-ui-2025/images/ui-development-medium-ui-version-a-level.png new file mode 100644 index 0000000..9d96a03 Binary files /dev/null and b/attestations-ui-2025/images/ui-development-medium-ui-version-a-level.png differ