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.
Conforms Basic
II. To derive a human-readable
subject name from an augmented assurance certificate, user agents MUST use the
Subject field's Organization (O) attribute.
Conforms Basic
Does Not Conform Basic
IV. User agents
Conforms Optional
V. User agents
Does Not Conform Optional - We
allow explicit pinning via the "exception" UI, but no implicit
pinning.
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
Conforms Advanced
Conforms Basic
VIII. At the
point of writing of this document, versions of SSL prior to SSLv3 [SSLv3] MUST NOT be considered strong.
Conforms Basic
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.
Conforms Basic
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.
Conforms Basic
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.
Conforms Basic
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.
Conforms Basic
XIII. User
agents
Conforms
Optional
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.
Conforms Basic
XV. User agents
Conforms Optional
XVI. When, during
Conforms Basic
XVII. When, during
Conforms Basic
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.
Conforms Basic
XIX. If
Conforms Basic
XX. When
Conforms
Optional
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.
Conforms Basic
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.
Conforms Basic
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.
Conforms Basic
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.
Conforms Advanced
XXVII. Otherwise, it MUST at
least be available through secondary
user interface.
Conforms Basic
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.
Conforms Basic
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.
Conforms Basic
XXX. In this case, user agents
MUST indicate that no information is available.
Conforms Basic
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.
Conforms Advanced
XXXII. Web Content MUST not
obscure security user interface, 7.4.1
Obscuring or disabling Security User Interfaces.
Conforms Basic
XXXIII. Information displayed in
the identity signal MUST be derived
from validated certificates, or from
user agent state.
Conforms Basic
XXXIV. Web user agents MUST NOT
use information as part of the identity
signal that is taken from unauthenticated or untrusted
sources.
Conforms Basic
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.
Conforms Basic
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.
Conforms Basic
XXXVII. User agents
Conforms
Optional
XXXVIII. The identity signal MUST
include the Issuer field's Organization attribute to inform the user about the
party responsible for that information.
Conforms Basic
XXXIX. Subject logotypes derived
from certificates MUST NOT be rendered, unless the certificate used is an augmented assurance certificate.
Conforms Basic
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.
Conforms Basic
XLI. In this situation, the
identity signal
Conforms
Optional
XLII. During interactions with
mixed content, user agents MUST NOT render any logotypes derived from
certificates.
Conforms Basic
XLIII. Web user agents MUST provide additional security context
information as described in this section.
Conforms Basic – redundant with the
items below
XLIV. Where security context
information is provided in both primary and secondary interface, the presentation
and meaning of the presented information MUST be consistent.
Conforms Basic
The information sources MUST
make the following security context information available:
XLV. the Web page's domain name
Conforms Basic
XLVI. Owner information, consistent with 6.1.2 Identity Signal Content
Conforms Basic
XLVII. Verifier information, consistent
with 6.1.2 Identity Signal Content
Conforms Basic
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.
Conforms Basic
The information
sources SHOULD make the following security context information available:
XLIX. What protection level is represented by
the TLS indicator;
Conforms Advanced
L.
If the Web page is weakly
Conforms Advanced
LI.
Whether the user has
visited the site in the past.
Conforms Advanced
Conforms Advanced
LIII.
Whether the site
content was encrypted in transmission.
Conforms Advanced
LIV. Whether the site content was
authenticated (e.g., server authentication via
Conforms Advanced – redundant with XLIX in this case.
Additionally, the information
sources
When the user most recently visited the
site in the past.
Does Not Conform Optional
LVI. When the user first visited the site in the past.
Does Not Conform Optional
LVII. How often the user visited the site in the past.
Conforms Optional
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.
Conforms Basic
LIX. User agents MUST make
information about the state of
Conforms Basic
LX. The [Definition:
Conforms Advanced
LXI. Otherwise, it MUST at least
be available through secondary user interface.
Conforms Basic
LXII. Web content MUST not
obscure security interface, 7.4.1
Obscuring or disabling Security User Interfaces.
Conforms Basic
LXIII. User interactions to
access the
Conforms Basic
LXIV. In this case, user agents
SHOULD indicate the interaction was not
Conforms Advanced
LXV. User agents with a visual
user interface that make the
Conforms Advanced
LXVI. The
Conforms Basic
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.
Conforms Advanced
LXVIII. The user agent
Conforms Optional
LXIX User agents
Does Not Conform Optional
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.
Conforms Advanced
LXXI. Primary user interface error messages MUST
NOT be phrased solely in terms of art.
Conforms Basic
LXXII. They SHOULD NOT refer the
user to enter the destination site that caused the error, e.g., to provide
feedback or obtain assistance.
Conforms Advanced
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.
Conforms Advanced
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.
Conforms Advanced
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.
Conforms Advanced
LXXVI. These warnings SHOULD be used
if the likelihood of danger is present, but cannot be confirmed.
Conforms Advanced
LXXVII. Warning / Caution
messages MUST interrupt the user's current task, such that the user must
acknowledge the message.
Conforms Basic
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).
Conforms Basic
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.
Conforms Basic
LXXX. One of the options offered
SHOULD be recommended, and the warning message SHOULD include a succinct text
component denoting which option is recommended.
Conforms Advanced
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.
Conforms Basic
LXXXII. Danger Messages MUST be
used when there is a positively identified danger to the user (i.e., not merely
a risk).
Conforms Basic
LXXXIII. The interactions
communicating these messages MUST be designed such that the user's task is
interrupted.
Conforms Basic
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.
Conforms Basic
LXXXV. For visual user agents,
agent chrome SHOULD always be present to signal security context information.
Conforms Advanced
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.
Conforms Basic
LXXXVII. Site-controlled content
(e.g. page title, favicon)
Conforms Optional
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.
Conforms Basic
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.
Conforms Advanced
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,
Conforms Basic
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.
Conforms Basic
XCII. A Web User Agent SHOULD
NOT display a modal security dialog related to a web page which does not
currently have focus.
Conforms Advanced
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..
Conforms Basic
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.
Conforms Basic
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.
Conforms Basic
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.
Conforms Basic
XCVII. Web user agents MUST NOT expose programming interfaces which
permit installation of software without a user intervention.
Conforms Basic
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.
Conforms Basic
XCIX. The interaction used MUST
follow the requirements in 6.4.2 Warning/Caution
Messages .
Conforms Basic
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.
Conforms Advanced
CI. User agents
Does Not Conform Optional
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.
Conforms Advanced
CIII. Web user agents MUST NOT permit Web content to add bookmarks
without explicit user consent.
Conforms Basic
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.
Conforms Advanced
CVI. User agents which offer
this restriction SHOULD offer a way to extend permission to individual trusted
sites.
Conforms Advanced