FIDO UAF Conformance Tool

107 views
Skip to first unread message

Jim D

unread,
Jun 4, 2019, 3:30:04 AM6/4/19
to FIDO Dev (fido-dev)
Hi,

Just wanted to harvest some other people's experience with the FIDO UAF Conformance Tool.  I've noticed it doesn't appear to be configurable with regards to:
  • 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).
  • 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.
  • 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.
None of these aspects appear to be overly dictated by the FIDO UAF specs, unless I've missed something.  We've managed to construct a proxy to intercept the Conformance Tool traffic and tweak the requests and responses to our liking, but I don't see this being possible if FIDO Certification is eventually applied for and the same tool needs to be used.

How have other people worked with these constraints?


Veera Venkatesh Chinthamadak

unread,
Jul 1, 2019, 11:22:55 AM7/1/19
to FIDO Dev (fido-dev)
HI all,

even I am going through the same observations and eagerly waiting for a response 

Dani Mező

unread,
Jul 1, 2019, 12:23:06 PM7/1/19
to Veera Venkatesh Chinthamadak, FIDO Dev (fido-dev)
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

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/3d58086a-0440-417f-9019-904d920cde11%40fidoalliance.org.
Reply all
Reply to author
Forward
0 new messages