For each of the conformance clauses of the specification, the Implementation report will list one of the six (colorful) phrases below. Additional notes may also be included. Only the conformance clauses are listed below; the full descriptions around each of the clauses may be found in wsc-ui.
(conforms to a MUST or MUST NOT)
Does Not Conform Basic
(conforms to a SHOULD or SHOULD NOT)
Does Not Conform Advanced
(conforms to a
Does Not Conform Optional
See wsc-ui Conformance section for details
Feature lettering maps features to table rows in Implementation Report roll up. Please also complete your column in that table.
I. Implementations MUST NOT enable users to designate trust roots as augmented assurance qualified as part of a different interaction.
II. To derive a human-readable subject name from an augmented assurance certificate, user agents MUST use the Subject field's Organization (O) attribute.
IV. User agents
V. User agents
VI. The interaction that enables users to pin a certificate to a
destination SHOULD NOT cause a self-signed certificate to be pinned to more
than one site, identified through
VIII. At the point of writing of this
document, versions of SSL prior to SSLv3 [SSLv3] MUST
NOT be considered strong.
IX. At the time of writing of this document, the "export" cipher suites explicitly forbidden in appendix A.5 of [TLSv11] MUST NOT be considered strong.
X. Any UI indicator used to signal the presence of Augmented Assurance certificates MUST NOT signal the presence of such a certificate, unless the page is TLS-secured, i.e., all parts of the page are loaded from servers presenting at least a validated certificate, over strongly TLS-protected interactions.
XI. If multiple error conditions apply, the most severe signaling level currently known MUST be used, as defined in 6.4 Error handling and signaling.
XIII. User agents
XIV. When certificate information is presented in the interactions described in this section, then human-readable information from certificates MUST NOT be presented as trustworthy unless it is attested to. e.g., a self-signed certificate's Common Name or Organization attribute MUST NOT be displayed, even if that certificate is pinned to a destination.
XV. User agents
XVI. When, during
XVII. When, during
XVIII. When the URL corresponding to the transaction at hand does not match the end-entity certificate presented, and a validated certificate is used, then error signaling of level danger (6.4.3 Danger Messages) MUST be used.
XXI. User agents that use third party services or heuristic approaches to assess the possible danger of a pending Web transaction MUST use error signaling of class danger (6.4.3 Danger Messages) to signal positively identified dangers, e.g., identified malicious downloads or exploits of user agent vulnerabilities.
XXII. To signal risks that are identified with high likelihood, but involve further user decisions (e.g., phishing heuristics were triggered), error signaling of class warning or above (6.4.2 Warning/Caution Messages , 6.4.3 Danger Messages) MUST be used.
XXIII. User agents SHOULD inform users, using an error of class Warning or higher (6.4.2 Warning/Caution Messages , 6.4.3 Danger Messages), when navigation between TLS-secured pages involves redirects which travel over weakly TLS-protected, or unsecured HTTP channels.
XXV. User agents MUST make information about the identity of the Web site that a user interacts with available.
XXVII. Otherwise, it MUST at least be available through secondary user interface.
XXVIII. If the identity signal is available, it MUST be part of primary user interface when any identity sources that are from unauthenticated or untrusted sources are (also) part of the primary user interface.
XXIX. User interactions to access this identity signal MUST be consistent across all Web interactions facilitated by the user agent, including interactions during which the user agent has no trustworthy information about the identity of the Web site that a user interacts with.
XXX. In this case, user agents MUST indicate that no information is available.
XXXI. User agents with a visual user interface that make the identity signal available in primary user interface SHOULD do so in a consistent visual position.
XXXII. Web Content MUST not obscure security user interface, 7.4.1 Obscuring or disabling Security User Interfaces.
XXXIV. Web user agents MUST NOT use information as part of the identity signal that is taken from unauthenticated or untrusted sources.
XXXV. The identity signal MUST include human-readable information about the certificate subject, derived as specified in 5.1.2 Augmented Assurance Certificates, to inform the user about the owner of the Web page.
XXXVI. If the identity signal does not include any other human readable information about the identity of the certificate subject (derived, e.g., from an augmented assurance certificate), then it MUST include an applicable DNS name that matches either the subject's Common Name attribute or its subjectAltName extension.
XXXVII. User agents
XXXVIII. The identity signal MUST include the Issuer field's Organization attribute to inform the user about the party responsible for that information.
XXXIX. Subject logotypes derived from certificates MUST NOT be rendered, unless the certificate used is an augmented assurance certificate.
XLI. In this situation, the
XLII. During interactions with mixed content, user agents MUST NOT render any logotypes derived from certificates.
XLIII. Web user agents MUST provide additional security context information as described in this section.
XLIV. Where security context information is provided in both primary and secondary interface, the presentation and meaning of the presented information MUST be consistent.
The information sources MUST make the following security context information available:
XLV. the Web page's domain name
XLVI. Owner information, consistent with 6.1.2 Identity Signal Content
XLVII. Verifier information, consistent with 6.1.2 Identity Signal Content
XLVIII. The reason why the displayed information is trusted (or not). This includes whether or not a certificate was accepted interactively, whether a self-signed certificate was used, and whether the self-signed certificate was pinned to the site that the user interacts with, and whether trust relevant settings of the user agent were otherwise overridden through user action.
The information sources SHOULD make the following security context information available:
XLIX. What protection level is represented by the TLS indicator;
If the Web page is weakly
LI. Whether the user has visited the site in the past.
LII. Whether the user has stored credentials for this site.
LIII. Whether the site content was encrypted in transmission.
Whether the site content was authenticated (e.g., server
LV. When the user most recently visited the site in the past.
LVI. When the user first visited the site in the past.
LVII. How often the user visited the site in the past.
LVIII. User agents that provide information about the presence or absence of Cookies [RFC2965] MUST NOT make any claims that suggest that the absence of cookies implies an absence of any user tracking, as there are numerous tracking and session management techniques that do not rely on Cookies.
LIX. User agents MUST make
information about the state of
LX. The [Definition:
LXI. Otherwise, it MUST at least be available through secondary user interface.
LXII. Web content MUST not obscure security interface, 7.4.1 Obscuring or disabling Security User Interfaces.
LXIII. User interactions to access
LXIV. In this case, user agents
SHOULD indicate the interaction was not
LXV. User agents with a visual
user interface that make the
LXVII. The User Agent SHOULD inform users when they are viewing a page that, along with all dependent resources, was retrieved through at least weakly TLS protected transactions, including mixed content.
LXVIII. The user agent
LXX. Error signaling that occurs as part of primary user interface SHOULD be phrased in terms of threat to user's interests, not technical occurrence.
LXXI. Primary user interface error messages MUST NOT be phrased solely in terms of art.
LXXII. They SHOULD NOT refer the user to enter the destination site that caused the error, e.g., to provide feedback or obtain assistance.
LXXIII. For error messages that interrupt the user's flow of interaction, user agents SHOULD enable the user to easily return to the user agent state prior to initiation of the last user interaction that led to the error signal.
LXXIV. For advanced users, error interactions SHOULD have an option for advanced users to request a detailed description of the condition that caused the interaction to occur.
LXXV. Warning / Caution messages MUST be used when the system has good reason to believe that the user may be at risk based on the current security context information, but a determination cannot positively be made.
LXXVI. These warnings SHOULD be used if the likelihood of danger is present, but cannot be confirmed.
LXXVII. Warning / Caution messages MUST interrupt the user's current task, such that the user must acknowledge the message.
LXXVIII. Warning / Caution messages MUST provide the user with distinct options how to proceed (i.e., these messages MUST NOT lead to a situation in which the only option presented to the user is to dismiss the warning and continue).
LXXIX. The options presented on these warnings MUST be descriptive to the point that their meanings can be understood in the absence of any other information contained in the warning interaction.
LXXX. One of the options offered SHOULD be recommended, and the warning message SHOULD include a succinct text component denoting which option is recommended.
LXXXI. In the absence of a recommended option, the warning MUST present the user with a method of finding out more information (e.g., a hyperlink, secondary window, etc) if the options cannot be understood.
LXXXII. Danger Messages MUST be used when there is a positively identified danger to the user (i.e., not merely a risk).
LXXXIII. The interactions communicating these messages MUST be designed such that the user's task is interrupted.
LXXXIV. These interactions MUST be presented in a way that makes it impossible for the user go to or interact with the destination web site that caused the danger situation to occur, without first explicitly interacting with the Danger Message.
LXXXV. For visual user agents, agent chrome SHOULD always be present to signal security context information.
LXXXVI. Web User Agents MUST NOT communicate trust information using user interface elements which can be mimicked within chrome under the control of web content.
LXXXVII. Site-controlled content
(e.g. page title, favicon)
LXXXVIII. but this content MUST NOT be displayed in a manner that confuses hosted content and chrome indicators, by allowing that content to mimic chrome indicators in a position close to them.
LXXXIX. In particular, Web User Agents SHOULD NOT use a 16x16 image in chrome to indicate security status if doing so would allow the favorite icon to mimic it.
XC. User interfaces used to inform users about security critical events or to solicit comment MUST employ techniques that prevent immediate dismissal of the user interface,
XCI. When users interact with security relevant notifications (6.4.2 Warning/Caution Messages and above), interactions caused by Web content MUST NOT be granted control of the user agent's interaction.
XCII. A Web User Agent SHOULD NOT display a modal security dialog related to a web page which does not currently have focus.
XCIII. Web user agents MUST prevent web content from obscuring, hiding, or disabling user interfaces that display security context information, except in response to a user interaction..
XCIV. User agents MUST restrict window sizing and moving operations consistent with 7.1 Keep Security Chrome Visible. This prevents attacks wherein agent chrome is obscured by moving it off the edges of the visible screen.
XCV. User agents MUST NOT allow web content to open new windows with the agent's security UI hidden. Allowing this operation facilitates picture-in-picture attacks, where artificial chrome (usually indicating a positive security state) is supplied by the web content in place of the hidden UI.
XCVI. User agents MUST prevent web content from overlaying chrome. This helps to ensure that user interactions that are perceived to target agent chrome are not redirected to Web applications.
XCVII. Web user agents MUST NOT expose programming interfaces which permit installation of software without a user intervention.
XCVIII. User agents MUST inform the user and request consent when the user agent is attempting to install software outside of the agent environment as a result of web content.
XCIX. The interaction used MUST follow the requirements in 6.4.2 Warning/Caution Messages .
C. User agents SHOULD NOT provide features which can be used by web content to install software outside of the agent environment without the user's consent.
CI. User agents
CII. User agents SHOULD inform the user when web content is installing software outside of the agent environment that is covered by a pre-consent.
CIII. Web user agents MUST NOT permit Web content to add bookmarks without explicit user consent.
CV. With visual user interfaces that use a windowed interaction paradigm, User agents SHOULD restrict the opening of pop-up windows from web content, particularly those not initiated by user action.
CVI. User agents which offer this restriction SHOULD offer a way to extend permission to individual trusted sites.