Skip to content
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.

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

Clarify uses of ClientData #209

Closed
gmandyam opened this issue Sep 17, 2016 · 5 comments
Closed

Clarify uses of ClientData #209

gmandyam opened this issue Sep 17, 2016 · 5 comments

Comments

@gmandyam
Copy link

gmandyam commented Sep 17, 2016

As per https://w3c.github.io/webauthn/#sec-client-data,

"The client data represents the contextual bindings of both the Relying Party and the client platform." This implies that authenticator contextual bindings are not included in the ClientData. Moreover, all dictionary entries listed in this section (challenge, rpId, etc.) do not represent values that are set by the authenticator.

Yet https://w3c.github.io/webauthn/#sec-android-attestation-signature defines platform-specific extensions to ClientData that are authenticator specific, which implies a contextual binding of the authenticator.

My suggestion is to prohibit such platform-specific extensions to ClientData.

@equalsJeffH equalsJeffH added this to the CR milestone Sep 20, 2016
@AngeloKai
Copy link
Contributor

I am confused about which extension you are concerned about. The section about Android attestation signature is not a extension. Can you illustrate more?

@gmandyam
Copy link
Author

Was referring to https://www.w3.org/TR/2016/WD-webauthn-20160531/#sec-android-attestation-signature. The issue was filed before the latest WD. It looks like the refactored attestation section eliminates platform-specific extensions to Client Data, so this issue may not be relevant anymore.

@vijaybh
Copy link
Contributor

vijaybh commented Nov 30, 2016

For extensions this is fixed in the current version at http://www.w3.org/TR/2016/WD-webauthn-20160928/#extension-client-processing and the attestation part is cleaned up under #244. Let's close this unless someone sees a reason why it's still relevant.

@equalsJeffH
Copy link
Contributor

#244 is an issue -- so you mean it "will be" cleaned up as a part of addressing #244 ?

@gmandyam
Copy link
Author

gmandyam commented Nov 30, 2016

@vijaybh

Sec. 4.10.1 currently (11/22/16) states "The client data represents the contextual bindings of both the Relying Party and the client platform. " My concern is the word "platform", because it seems to open the door to platform-specific extensions to clientData, which I think we want to avoid. Can we simplify to just "client"?

vijaybh added a commit that referenced this issue Jan 10, 2017
Refactor the attestation section to clean up exposition. Separated out
signature verification (per format) from trust chaining (done at higher
layer).

Created a separate section for specifying key RP operations. Fixes #88.

RP registration section defines binding of credentials to user accounts.
Fixes #13.

RP registration section also defines options in case of registering the
same credential to different users. Fixes #12.

Cleans up and completes defining the process for verifying assertions,
which had already been largely done by @rlin1. Fixes #102.

Completes drawing the distinction between assertion and attestation
certificates. Fixes #118.

Replace "client platform" with "client" in signature format section to
avoid confusion. Fixes #209.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants