Skip to content

fix #204: factor makeCred into reg & authn priv considerations #777

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Feb 7, 2018
Merged

fix #204: factor makeCred into reg & authn priv considerations #777

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b77a5eb
factor makeCred into reg & authn priv cons
Feb 6, 2018
381bbf0
refer to ceremony rather than operation
Feb 7, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 13 additions & 10 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4595,21 +4595,24 @@ in several ways, including:
signature using the [=ECDAA-Issuer public key=], but the attestation signature does not serve as a global correlation handle.


## Authentication Ceremonies ## {#sec-assertion-privacy}
## Registration and Authentication Ceremonies Privacy ## {#sec-assertion-privacy}

In order to protect the user from being identified without [=user consent|consent=], implementations of the
{{PublicKeyCredential/[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)}} method need to take care to
not leak information that could enable the [=[RP]=] to distinguish between these cases:
In order to protect users from being identified without [=user consent|consent=], implementations of the
{{PublicKeyCredential/[[Create]](origin, options, sameOriginWithAncestors)}} and
{{PublicKeyCredential/[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)}} methods need to take care to
not leak information that could enable a malicious [=[RP]=] to distinguish between these cases, where "named" means that the
[=public key credential|credential=] is listed by the [=[RP]=] in either {{MakePublicKeyCredentialOptions/excludeCredentials}}
or {{PublicKeyCredentialRequestOptions/allowCredentials}}, as applicable:

- A named [=public key credential|credential=] is not available.
- A named [=public key credential|credential=] is available, but the user does not [=user consent|consent=] to use it.

If the above cases are distinguishable, information is leaked by which a malicious [=[RP]=] could identify the user by probing for
which [=public key credential|credentials=] are available. For example, one such information leak is if the client returns a
failure response as soon as the user denies [=user consent|consent=] to proceed with the operation. In this case the [=[RP]=]
could detect that the operation was canceled by the user and not the timeout, and thus conclude that at least one of the [=public
key credential|credentials=] listed in the {{PublicKeyCredentialRequestOptions/allowCredentials}} parameter is available to the
user.
If the above cases are distinguishable, information is leaked by which a malicious [=[RP]=] could identify the user by probing
for which [=public key credential|credentials=] are available. For example, one such information leak is if the client returns a
failure response as soon as the user denies [=user consent|consent=] to proceed with a [=registration=] or [=authentication=]
[=ceremony=]. In this case the [=[RP]=] could detect that the [=ceremony=] was canceled by the user and not the timeout, and
thus conclude that at least one of the [=public key credential|credentials=] listed in the
{{PublicKeyCredentialRequestOptions/allowCredentials}} parameter is available to the user.


# Acknowledgements # {#acknowledgements}
Expand Down