Hi Jim, Veera,
I think one of the premises of the FIDO UAF Conformance tool, is that anything that is not specified by the FIDO UAF specification, has to be flexible in your implementation. I think this is fair game, since otherwise they'd be the one that has to implement a super flexible FIDO Client. If they did that, that would be ideal for sure - but they didn't.
HTTP endpoints at the FIDO Server (e.g. the tool expects to use /get for a registration request and /respond to submit the registration response).
Yup, this is inconvenient, but I think it falls into the premise. I'd suggest to create new controller wrappers around your existing ones, or just have a gateway/proxy in between - as you mentioned it as well.
The 'context' field of the UAF request. We'd like to include some additional domain-specific values in here, which we should be able to do without breaking the FIDO specification.
You can add anything there without breaking the specification, but I think your FIDO Server implementation must be able to execute the FIDO operations irregardless of the context object, musn't it? You may extend the protocol with domain information, but you cannot expect other party clients to adhere to it. (And the FIDO conformation process is all about whether your server can work with other party clients)
Expected HTTP status codes (as opposed to the UAF status codes). E.g. we'd like to send a 4xx HTTP status code if something went wrong, as well as the appropriate UAF status code in the UAF response body, but the tool always seems to expect a 2xx HTTP response regardless of what's happened, and will fail the scenario even if we have included the expected UAF status code such as 1498.
I disagree with this idea. The UAF protocol builds upon HTTP. The HTTP status codes suppose to describe the nature of client-server communication, but not the business that operates underneat. Of course REST changes this, but UAF is not built for REST. If there is something up with the server-client communication (like wrong JSON payload or content type), that should be reflected by the HTTP statuscode. If there is something up on the FIDO level (like wrong UafResponse structure or assertion type), it should NOT be reflected on the HTTP statuscode, but on the UAF statuscode instead.
Just my two pence,
Cheers,
Daniel