-
Notifications
You must be signed in to change notification settings - Fork 167
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
Spec should not mandate behavior of server #88
Comments
For relevant points, see:
Like attestation statements and signature formats, this sort of information is useful to those that are trying to use the APIs. Suggesting broad adoption of some set of crypto / attestation formats is important to make sure implementations are broadly interoperable. Also, Section 4.3.3 is generally important to make sure that a server is doing its appropriate security diligence. |
+1 to Adam. Whether or not this is the correct document is another matter but if it is not in this document, it should remain in the FIDO 2.0 specifications. |
+1 to Adam. This spec is more than just an API, it also defines a (cryptographic) protocol between a "challenger/verifier" and a "signer".. https://docs.google.com/presentation/d/1om__oSew4n48MK_Qcc8deq6hCZ6720-Zvv1PdK0CrjA ..which happen to be a server and a client, respectively. As is commonly done in protocol specs, this spec (at least) needs to provide "implementation considerations" describing the ramifications of various implementation choices on the part of both servers and clients. |
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.
fwiw, this issue was closed by eliminating the language objected to by @leshi but without addressing concerns expressed by @apowers313, nor without expressing a plan to address the need for denoting server implementation considerations somewhere. |
The latest spec does seem to have language about what's expected algorithmically, such as verifying an assertion and verifying attestation. (Although not validating an attestation statment). This seems to be comparable to what was noted as The former language of It would be nice if W3C made some recommendations to get ahead of interoperability issues. |
reopening so we don't loose track of this |
This spec already describes two conformance classes: the UA/Client and the Authenticator. Adding a third, the Relying Party, seems reasonable to me, and I don't think it's terrible to keep it in this document. UA implementers will just be able to ignore that section. It is, of course, important to specify the UA without assuming the Relying Party behaves as specified and vice versa, but I don't see violations of that in the current spec. I would suggest that the Relying Party spec specify the whole sequence of operations around the call to |
I agree that we need to continue specifying any security-critical server behaviors. We can decide to move them into their section if people feel strongly about this but I would object to removing them entirely. |
+1 to @jyasskin in particular:
Agreed. and another one is that the challenge be generated on the RP server-side. |
The spec already has an extensive server behavior section. The section is considered descriptive suggestion to server. According the comments above, it seems the consensus is the issue should be closed. Should we close the issue? @equalsJeffH @jyasskin |
Removing the type:technical label. This doesn't impact the API interface or behavior. |
* Add a Relying Party conformance class. Fixes #88. * Link "Relying Party".
This specification should minimally specify (if at all) behavior for servers. This spec is about client behavior and statements like "servers MUST support all types of attestation" are not appropriate.
The text was updated successfully, but these errors were encountered: