Use CAPS for normative requirements

Co-authored-by: Emil Lundberg <[email protected]>

index.bs

@@ -2992,7 +2992,7 @@ the operation succeeded. A successfully resolved promise only means that the
 <code>options</code> object was well formed.
 
 Each [=signal method=] includes <dfn for="signal method">authenticator
-actions</dfn>. [=Authenticators=] may choose to deviate in their [=signal
+actions</dfn>. [=Authenticators=] MAY choose to deviate in their [=signal
 method/authenticator actions=] from the present specification, e.g. to ignore a
 change they have a reasonable belief would be contrary to the user's wish, or to
 ask the user before making some change. [=signal method/Authenticator actions=]
@@ -9338,7 +9338,7 @@ the [=[RP]=] could mitigate the privacy leak using the same approach of returnin
 as discussed in [[#sctn-username-enumeration]].
 
 When [=signal methods|signalling=] that a [=credential id=] was not recognized,
-the [=[WRP]=] should use the
+the [=[WRP]=] SHOULD use the
 {{PublicKeyCredential/signalUnknownCredential(options)}} method instead of the
 {{PublicKeyCredential/signalAllAcceptedCredentials(options)}} method to avoid
 exposing [=credential IDs=] to an unauthenticated caller.