Server front-end example index.html does not adhere to a standard server transport specification

sbweeden commented 2 years ago

By submitting this issue you are acknowledging that any information regarding this issue will be publicly available.

If you have privacy concerns, please email conformance-tools@fidoalliance.org

FIRST PRE CHECK

[ X] I SOLEMNLY SWEAR THAT I HAVE SEARCHED DOCUMENTATION AND WAS NOT ABLE TO RESOLVE MY ISSUE

What protocol are you implementing?

[X ] FIDO2 Server
[ ] CTAP2.0
[ ] CTAP2.1
[ ] UAF 1.1
[ ] U2F 1.1
[ ] U2F 1.2

NOTE: UAF 1.0 certification have been officially sunset. U2F 1.2 only supported version of U2F.

What is your implementation class?

[ ] Security Key / FIDO2 / U2F authenticators
[X ] Server
[ ] UAF Client-ASM-Authenticator combo
[ ] UAF Client
[ ] UAF ASM-Authenticator

If you are platform authenticator vendor, please email conformance-tools@fidoalliance.org

What is the version of the tool are you using?

Server front-end index.html

What is the OS and the version are you running?

Irrelevant

For desktop tools

[ ] OSX
[ ] Windows
[ ] Linux

For UAF mobile tools

[ ] iOS
[ ] Android

Issue description

The server front-end index.html does not conform to any normative server specification.

The "last known" version of a server specification I could find is here

This is very out of date, and the server front-end example index.html doesn't adhere to it either. If interoperability servers are going to be asked to expose this front-end, then the expected HTTP payload interfaces need to be specified.

Specific examples of non-compliant request payloads include:

Example 1: In /assertion/options an example request is:

{
  "displayName": "Mozell Shue",
  "username": "mozellshue@grapefruitdouble.eg"
}

The displayName field is not part of any specification for /assertion/options and should not be included.

Example 2: In /assertion/result an example request is:

{
  "rawId": "DVFWhM2Ye9-0wKtnvsKkEKbFNwx8ESl8OuRbJVBdh0OmAuT4lrHqQPmp-OWHkYRqPEigUqCGRyWJsIZCocQ1rA",
  "response": {
    "authenticatorData": "xKd7U13zA_foEVgh7zx7TZX1xiy6BBHLnAyCVzrZ9lkFAAAABA",
    "signature": "MEUCIGn_2qr1-89VxfgO6aMGpVpzeUt0rX6QxSSlC9Iu3SrTAiEApzQh0aUn9EdU7cw3dLceQp4Anc26CdkhBt1qRv6bbrM",
    "userHandle": null,
    "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uZ2V0IiwiY2hhbGxlbmdlIjoiZjhraVY3NTNWdnVEMFdHT3kxX2FOaXJZeUZRa3lNSEVXOEpSZlVEa3ZsSSIsIm9yaWdpbiI6Imh0dHBzOi8vZmlkb2ludGVyb3AudmVyaWZ5LmlibS5jb206ODQ0MyIsImNyb3NzT3JpZ2luIjpmYWxzZX0"
  },
  "authenticatorAttachment": "cross-platform",
  "getClientExtensionResults": {},
  "id": "DVFWhM2Ye9-0wKtnvsKkEKbFNwx8ESl8OuRbJVBdh0OmAuT4lrHqQPmp-OWHkYRqPEigUqCGRyWJsIZCocQ1rA",
  "type": "public-key"
}

The authenticatorAttachment field is new to L3 of WebAuthn and not currently part of the server specification for /assertion/result.

Example 3: In /attestation/response an example body is:

{
  "rawId": "q3XAGKdtgUNM14o1R1lNmXDL6SaXKGRJC3mDOfFYBCV60EmS1EXeBScOCaZHWfz24c97L_InQ48KvnBZXajrJw",
  "response": {
    "attestationObject": "o2NmbXRmcGFja2VkZ2F0dFN0bXSjY2FsZyZjc2lnWEcwRQIhAOwu9u1uVaHDzVv7NKNvQqz0H1heMC6b1siyHTAvcMJhAiBOAmtgawEF3D70UKSEKutuDjPdY5oj_Pq_QtvtEL85VGN4NWOBWQLBMIICvTCCAaWgAwIBAgIEK_F8eDANBgkqhkiG9w0BAQsFADAuMSwwKgYDVQQDEyNZdWJpY28gVTJGIFJvb3QgQ0EgU2VyaWFsIDQ1NzIwMDYzMTAgFw0xNDA4MDEwMDAwMDBaGA8yMDUwMDkwNDAwMDAwMFowbjELMAkGA1UEBhMCU0UxEjAQBgNVBAoMCVl1YmljbyBBQjEiMCAGA1UECwwZQXV0aGVudGljYXRvciBBdHRlc3RhdGlvbjEnMCUGA1UEAwweWXViaWNvIFUyRiBFRSBTZXJpYWwgNzM3MjQ2MzI4MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEdMLHhCPIcS6bSPJZWGb8cECuTN8H13fVha8Ek5nt-pI8vrSflxb59Vp4bDQlH8jzXj3oW1ZwUDjHC6EnGWB5i6NsMGowIgYJKwYBBAGCxAoCBBUxLjMuNi4xLjQuMS40MTQ4Mi4xLjcwEwYLKwYBBAGC5RwCAQEEBAMCAiQwIQYLKwYBBAGC5RwBAQQEEgQQxe9V_62aS5-1gK3rr-Am0DAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBCwUAA4IBAQCLbpN2nXhNbunZANJxAn_Cd-S4JuZsObnUiLnLLS0FPWa01TY8F7oJ8bE-aFa4kTe6NQQfi8-yiZrQ8N-JL4f7gNdQPSrH-r3iFd4SvroDe1jaJO4J9LeiFjmRdcVa-5cqNF4G1fPCofvw9W4lKnObuPakr0x_icdVq1MXhYdUtQk6Zr5mBnc4FhN9qi7DXqLHD5G7ZFUmGwfIcD2-0m1f1mwQS8yRD5-_aDCf3vutwddoi3crtivzyromwbKklR4qHunJ75LGZLZA8pJ_mXnUQ6TTsgRqPvPXgQPbSyGMf2z_DIPbQqCD_Bmc4dj9o6LozheBdDtcZCAjSPTAd_uiaGF1dGhEYXRhWMTEp3tTXfMD9-gRWCHvPHtNlfXGLLoEEcucDIJXOtn2WUUAAAABxe9V_62aS5-1gK3rr-Am0ABAq3XAGKdtgUNM14o1R1lNmXDL6SaXKGRJC3mDOfFYBCV60EmS1EXeBScOCaZHWfz24c97L_InQ48KvnBZXajrJ6UBAgMmIAEhWCAIlt6UdADkI6QW_NS12TWPQmI4-AUHSJ9y3GLbgbLxrSJYIIJbrTR6sJozYo3EZAGund6szzSMtXHqRxDXR03i8vLm",
    "getAuthenticatorData": {},
    "getPublicKey": {},
    "getPublicKeyAlgorithm": {},
    "getTransports": {},
    "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiQWFiM1M5VjFKWUN4Vmd2OGhucGwyRmpIcEN5ci1FNnpKUGhFNjd6VlVlYyIsIm9yaWdpbiI6Imh0dHBzOi8vZmlkb2ludGVyb3AudmVyaWZ5LmlibS5jb206ODQ0MyIsImNyb3NzT3JpZ2luIjpmYWxzZX0"
  },
  "authenticatorAttachment": "cross-platform",
  "getClientExtensionResults": {},
  "id": "q3XAGKdtgUNM14o1R1lNmXDL6SaXKGRJC3mDOfFYBCV60EmS1EXeBScOCaZHWfz24c97L_InQ48KvnBZXajrJw",
  "type": "public-key"
}

The following included elements of that response are not part of any specification:

getAuthenticatorData
getPublicKey
getPublicKeyAlgorithm
getTransports
- Even though transports are actually available, they are not conveyed at all since the implementation of publicKeyCredentialToJSON in index.html doesn't call the getTransports function, but instead treats it as a data-carrying element.
authenticatorAttachment
- Same as the assertion/result, this is relatively new to WebAuthn L3, and is provided by Chrome for example, but is not part of any server specification.

yackermann commented 2 years ago

Hey Shane.

We do no use server specs anymore, as TWG decided to remove reference API from the server spec.

Official conformance API is here: https://github.com/fido-alliance/conformance-test-tools-resources/blob/master/docs/FIDO2/Server/Conformance-Test-API.md

Re issues: That seems to be just typoe that no one noticed

yackermann commented 2 years ago

Re typoes: They are not present in conformance API definition anymore

fido-alliance / conformance-test-tools-resources