fix linking errors, ref PublicKeyCredentialCreationOptions rather tha…

…n MakePublicKeyCredentialOptions (#840)

merging on @AngeloKai's request.

index.bs

@@ -4790,7 +4790,7 @@ in several ways, including:
 In order to protect users from being identified without [=user consent|consent=], implementations of the
 {{PublicKeyCredential/[[Create]](origin, options, sameOriginWithAncestors)}} method need to take care to not leak information that
 could enable a malicious [=[RP]=] to distinguish between these cases, where "excluded" means that at least one of the [=public key
-credential|credentials=] listed by the [=[RP]=] in {{MakePublicKeyCredentialOptions/excludeCredentials}} is bound to the
+credential|credentials=] listed by the [=[RP]=] in {{PublicKeyCredentialCreationOptions/excludeCredentials}} is bound to the
 [=authenticator=]:
 
 - No [=authenticators=] are present.
@@ -4801,7 +4801,7 @@ which [=public key credential|credentials=] are available. For example, one such
 failure response as soon as an excluded [=authenticator=] becomes available. In this case - especially if the excluded
 [=authenticator=] is a [=platform authenticator=] - the [=[RP]=] could detect that the [=ceremony=] was canceled before the
 timeout and before the user could feasibly have canceled it manually, and thus conclude that at least one of the [=public key
-credential|credentials=] listed in the {{MakePublicKeyCredentialOptions/excludeCredentials}} parameter is available to the user.
+credential|credentials=] listed in the {{PublicKeyCredentialCreationOptions/excludeCredentials}} parameter is available to the user.
 
 The above is not a concern, however, if the user has [=user consent|consented=] to create a new credential before a
 distinguishable error is returned, because in this case the user has confirmed intent to share the information that would be