WebAuthn Level 2

[mulderr]

Hi!

There's a new W3C Recommendation from 8 April 2021, Level 2. There have been at least a couple significant changes. Do you have any plans to implement the new version of the specification?

I've been taking a stab at it myself, mostly as an excercise to better understand WebAuthn. Code here. It's gotten a bit out of hand. Up to a point where I think it would perhaps be good to merge it here eventually? What do you think?

I've already made same possibly opinionated choices but those are probably up for discussion:

• removed dependency on deriving-aeson and base16-bytestring
• replaced base64-bytestring with base64 which has explicit versions for parsing unpadded base64 url encoding
• removed all field prefixes in favor of DuplicateRecordFields (and in anticipation of NoFieldSelectors, OverloadedRecordDot...)
• annotated everything with references to the spec
• renamed all datatypes and fields to match names in the spec

Also:

• implemented hopefully most of the updated 7.1 and 7.2 procedures
• added some missing datatypes
• commented out extenion releated things, Level 2 adds new ones, removes some old ones, didn't have time to get to that yet
• moved some code around
• lots more...

In the process I've definitely broken wai-middleware-webauthn and probably most of the tests but those are probably not the most urgent issues. Things are in flux anyway, there's probably lots to be done still.

[fumieval]

There seems to be significant changes indeed. I'm all for merging your changes; if we were to make breaking changes, maybe we should develop a new API with GHC 9.2 (I don't really want to use DuplicateRecordFields with <9.2)

[mulderr]

That sounds good. I'm fine with assuming GHC >= 9.2 here but as a side note I think the goal should also be maximizing value to the community, so ease of use with popular tooling like stack and nix should eventually become a factor - preferably once they catch up to 9.2 and going forward.

So the short term plan is:

• switch to GHC 9.2 (still in alpha), fix any build errors
• disable DuplicateRecordFields, enable NoFIeldSelectors etc.
• fix tests
• create a PR so we can go over details?

Does that sound about right?

[fumieval]

Yeah that sounds good

[mulderr]

Even with 9.0.1 build fails due to foundation, memory, cryptonite... stopped researching there, there's probably more. GHC 9.0.1 was released 2021-02-04 so realistically it could be months before 9.2 is actually usable for us.

If DuplicateRecordFields is a blocker, are there any acceptable alternatives? I'd even rather go through the pain of prefixing everything and then going back when possible. Though that would be a huge mess both in terms of work and breakage.

[fumieval]

foundation is no longer maintained AFAIK. I'll see if I can replace the dependencies

[mulderr]

In the meantime I've added a little demo modeled after webauthn.io.

[mulderr]

Got access to testing tools from FIDO Alliance. Hoping to run some tests soonish.

License forbids sharing the tools but the request form is a formality really. Got a reply after a couple hours with a link.

[mulderr]

Added a test server for testing with FIDO Tools - they require specific endpoints with specific json requests and responses. It probably makes sense to eventually merge the demo and test server.

Most of the tests are surprisingly passing but in this case that is little cause for joy because many of them are of the kind "server returns an error when...". Therefore a server can for example pass 81 of 98 attestation tests simply returning 404 Not Found to every request :)

Current status:

• MakeCredential Request: 3 passes, 0 failures
• MakeCredential Response: 83 passes, 15 failures
• GetAssertion Request: 2 passes, 0 failures
• GetAssertion Response: 49 passes, 3 failures
• Metadata Service Tests - not checked

Aditionally the 3 failures for assertion response are related to a possible contradition between the spec and tests. Spec requires User Present bit to be set but tests expect server to return success when it's not set. Some of the other projects are confused about it too. To the point they disable the check required by the spec. Doesn't seem like a good idea. I've asked FIDO Certification Team for clarification.

[mulderr]

Small status update. First, I've not given up on this yet! Second, no response came from FIDO, I'm not sure that I've directed my question to the right place or asked it the right way, that may be the problem. Third, GHC 9.2 is out, yay! Bad news it's only just out so neither stackage nor nixpkgs use it yet.

[fumieval]

I've just merged a massive rework (#21). I don't know about stack but I added a cabal.project which makes it buildable on GHC 9.2.1.

Apologies for the huge churn. I'm trying to gradually make the source closer to your fork