Webauthn: Spec should not mandate behavior of server

[leshi]

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.

[apowers313]

For relevant points, see:

• Section 4.3.1: Compliant servers MUST support all attestation models. Authenticators can choose what attestation model to implement.
• Section 4.3.2.1.2: The signature is computed over the rawData field. The following algorithms must be implemented by servers:
• Section 6.5: Servers supporting UVI extensions MUST support a length of up to 32 bytes for the UVI value.
• Section 4.3.3: Upon receiving an attestation statement, the WebAuthn Relying Party shall:

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.

[jovasco]

+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.

[equalsJeffH]

+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.

[equalsJeffH]

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.

[apowers313]

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 Section 4.3.3 above.

The former language of Section 4.3.1 and Section 4.3.2.1.2 specified what crypto and attestation formats a server would need to support. This becomes a interoperability issue. For example, if authenticators implement either ECDSA or RSA and servers support either ECDSA or RSA there is some set of servers and authenticators that simply will not work together because they don't support the same cipher suites.

It would be nice if W3C made some recommendations to get ahead of interoperability issues.

[equalsJeffH]

reopening so we don't loose track of this

[jyasskin]

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 makeCredential()/ScopedCredential.create() or getAssertion()/navigator.credentials.get({scoped}) instead of just the code after those functions return. One problem with only specifying the suffix is that it omits the requirement that challenge be a nonce.

[selfissued]

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.

[equalsJeffH]

+1 to @jyasskin

in particular:

One problem with only specifying the suffix is that it omits the requirement that challenge be a nonce.

Agreed. and another one is that the challenge be generated on the RP server-side.

[AngeloKai]

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

[AngeloKai]

Removing the type:technical label. This doesn't impact the API interface or behavior.