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 Basic
(conforms to a MUST or MUST NOT)
Does Not Conform Basic
Conforms Advanced
(conforms to a SHOULD or SHOULD NOT)
Does Not Conform Advanced
Conforms Optional
(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.
XII. Error signaling of class warning or
higher (6.4.2 Warning/Caution Messages , 6.4.3 Danger Messages) MUST be used to signal
the error condition.
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.
XIX. If
XX. When
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.
XXIV. User agents
XXV. User agents MUST make
information about the identity of the Web site that a user interacts with
available.
XXVI. This [Definition: identity signal ] SHOULD
be part of primary user interface
during usage modes which entail the presence of signaling to the user beyond
only presenting page content.
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.
XXXIII. Information displayed in
the identity signal MUST be derived
from validated certificates, or from
user agent state.
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.
XL. During interactions with a mixed content Web page, the identity signal MUST NOT include any
site identity information exceeding those in use for unprotected HTTP
transactions.
XLI. In this situation, the
identity signal
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;
L.
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.
LIV.
Whether the site content was authenticated (e.g., server
authentication via
Additionally, the
information sources
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
the
LXIV. In this case, user agents
SHOULD indicate the interaction was not
LXV. User agents with a visual
user interface that make the
LXVI. 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
LXIXUser agents
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.