diff --git a/index.html b/index.html index 17182b97..9b9ef27a 100644 --- a/index.html +++ b/index.html @@ -4711,38 +4711,47 @@
-Additional information about the security context of authentication events
-is often required for compliance reasons, especially in regulated areas
-such as the financial and public sectors. Examples include but are not
-limited to protection of secret keys, the identity proofing process, and the
-form-factor of the authenticator. For example,
+
+
+
Payment services (PSD 2) and
eIDAS introduce such requirements to the security context. Level of
-Assurance (LoA) frameworks are classified and defined by, for example,
-
-eIDAS,
-
-NIST 800-63-3 and
-ISO/IEC 29115:2013, including their requirements for the security
-context, and making recommendations on how to achieve them. This might
-include strong user authentication and , NIST 800-63-3 and ISO/IEC
+29115:2013, including their requirements for the security context, and
+making recommendations on how to achieve them. This might include strong user
+authentication where FIDO2/WebAuthn can be potential
-implementations. A LoA represents the level of confidence that an entity is in
-fact that entity. Some regulated use cases require the implementation of a
-certain LoA. Since verification relationships such as
+href="https://www.w3.org/TR/webauthn-2/">WebAuthn
+Some regulated scenarios require the implementation of a specific level of
+assurance. Since verification relationships such as
assertionMethod
and authentication
might be
-used in some of these use cases, information about the applied security context
-might need to be expressed and provided to a verifier.
-Whether and how to encode this information in the DID document data model
-is out of scope for this specification, but it should be noted that the DID
-document data model can be extended if necessary (see Extensibility section). Section Privacy Considerations remains applicable for
-such extensions.
+used in some of these situations, information about the applied security context
+might need to be expressed and provided to a verifier. Whether and how
+to encode this information in the DID document data model is out of scope
+for this specification. Interested readers might note that 1) the information
+could be transmitted using Verifiable Credentials [[?VC-DATA-MODEL]], and 2) the
+DID document data model can be extended to incorporate this information
+as described in , and where is applicable for such extensions.