Address Lucas and Emil's comments

index.bs

@@ -4514,9 +4514,9 @@ In order to perform a [=registration ceremony=], the [=[RP]=] MUST proceed as fo
 
 1. Check that the <code>[=credentialId=]</code> is &le; 1023 bytes. Credential IDs larger than this many bytes SHOULD cause the RP to fail this [=registration ceremony=].
 
-1. Check that the <code>[=credentialId=]</code> is not yet registered for any user. If it is, the [=[RP]=] MUST fail this [=registration ceremony=].
+1. Check that the <code>[=credentialId=]</code> is not yet registered for any user. If the <code>[=credentialId=]</code> is already known then the [=[RP]=] SHOULD fail this [=registration ceremony=].
 
-    NOTE: The rationale for [=[RPS]=] rejecting duplicate [=credential IDs=] is as follows: [=credential IDs=] contain sufficient entropy that the case of accidental duplication can be ignored. However, [=attestation types=] other than [=self attestation=] do not include a self-signature explicitly proving possession of the [=credential private key=] at [=registration=] time. Thus an attacker who has managed to obtain a user's [=credential ID=] for a site (this could be potentially accomplished in various ways), could attempt to register a victim's credential as their own at that site. If the [=[RP]=] accepts this new registration and replaces the victim's existing credential registration, and the [=discoverable credentials|credentials are discoverable=], then the victim could be forced to sign into the attacker's account at their next attempt. Data saved to the site by the victim in that state would then be available to the attacker.
+    NOTE: The rationale for [=[RPS]=] rejecting duplicate [=credential IDs=] is as follows: [=credential IDs=] contain sufficient entropy that accidental duplication is very unlikely. However, [=attestation types=] other than [=self attestation=] do not include a self-signature to explicitly prove possession of the [=credential private key=] at [=registration=] time. Thus an attacker who has managed to obtain a user's [=credential ID=] and [=credential public key=] for a site (this could be potentially accomplished in various ways), could attempt to register a victim's credential as their own at that site. If the [=[RP]=] accepts this new registration and replaces the victim's existing credential registration, and the [=discoverable credentials|credentials are discoverable=], then the victim could be forced to sign into the attacker's account at their next attempt. Data saved to the site by the victim in that state would then be available to the attacker.
 
 1. If the attestation statement |attStmt| verified successfully and is found to be trustworthy, then register the new
     credential with the account that was denoted in <code>|options|.{{PublicKeyCredentialCreationOptions/user}}</code>: