Add clarifications to the metadata service tests

[yackermann]

Implementors seem to be getting confused about our test policy. Would be good idea to add clarifications.

[aseigler]

Speaking for myself, it would have made much more sense if instead of calling the metadata service test inputs "endpoints", they were referred to as custom metadata table of contents objects, which must be parsed per the metadata TOC object processing rules, with valid metadata statements stored in a dictionary. When the tests are run, that dictionary must be used when processing incoming attestation responses, with authenticators missing from the dictionary or having an undesirable authenticator status being rejected.

Figuring out that had to load the metadata statements from the conformance tool into that same dictionary without a TOC was much easier, but it still would be nice to have some direction for that as well.

[bdewater]

I found this to be quite confusing to implement with no documentation available, needing to use a combination of trial and error, and looking at how the .net library does certain things.

Did I miss anything? 😕 I looked here:

• The Server Requirements and Transport Binding Profile document is a good reference for the test tool itself, it mentions nothing about how the MDS tests are supposed to be carried out.
• The PDF files on the conformance tool download site had nothing.
• The tool itself only giving a confirmation dialog whether I had added the conformance MDS endpoints to my application, without further explanation of how to use these.

For https://github.com/cedarcode/webauthn-ruby I've arrived at something that does this:

• Make an application/json POST request to https://fidoalliance.co.nz/mds/getEndpoints with { "endpoint": "my endpoint" } as the request body - similar to what the https://fidoalliance.co.nz/mds/ website does.
• In the response, loop over the URLs in the result key. For each one, make an application/json GET request and try to process it according to the Metadata Service processing rules. Most of these JWTs will fail processing because they're invalid somehow.
• One of these URLs should return a valid JWT, parse that into an object that represents the TOC. Store it in a cache and use it to run the test cases with the tools provides.
• Realized this only just now: the MDS endpoints only cover the MDS test cases. The TOC rom the step above doesn't have the same AAGUIDs as the other tests use. In order to run all the other test cases you need to use the 'download server metadata' button inside the tool and load the zipped statements into your cache as well.