Interop with other implementations

[pmlopes]

Hi, I'm the developer of Eclipse Vert.x webauthn RP library, a JVM based library. I've noticed that most of the projects out there overlap in the sense that we keep implementing a RP library and some JS/TS FE glue library. I'd like to see how interesting would it be if we could work to get some common set of requirements:

• msg schema
• status code
• error handling

That projects could adhere in a non normative way so we could ease the integration. As an example, I believe this project provides a great FE library already, including the new conditional UI features and I believe that having to recreate it again to interop with a Eclipse backend would be a waste of time as we could just tell users to pick (your) project that works great.

My idea is that if we would define a non normative set of rules for integration, we could work together to get webauthn adopted faster with fully tested and feature rich libraries, that having lots of forks that sometimes don't keep up with the spec and miss features.

What are your thoughts on this?

[MasterKale]

Hey @pmlopes, this is an interesting idea. WebAuthn is an odd duck in that it has both front end and back end responsibilities, and naturally there's a desire to make it easy to abstract away the coordination between the two. After all that's why I undertook both sides of that effort with SimpleWebAuthn: it was important to me that I try to make it easy to use because I knew I'd tear my hair out if I had to reimplement most of this stuff every time.

That projects could adhere in a non normative way so we could ease the integration.

In retrospect I think I already kicked off such an attempt to create a common interface between front end and backend when I re-wrote Duo's py_webauthn library. I confess I simply wrote the new methods to @simplewebauthn/browser's inputs and outputs because it made it easy for me to manually test out the library using the front end library I knew best 😇

In regards to the three bullet points above:

• msg schema

I'd argue the basis for, if not the answer to, this is this project's PublicKeyCredentialCreationOptionsJSON and PublicKeyCredentialRequestOptionsJSON:

• SimpleWebAuthn/packages/typescript-types/src/index.ts

  Line 26 in cfa6892

  export interface PublicKeyCredentialCreationOptionsJSON

• SimpleWebAuthn/packages/typescript-types/src/index.ts

  Line 38 in cfa6892

  export interface PublicKeyCredentialRequestOptionsJSON

And of course the output from startRegistration() and startAuthentication():

• SimpleWebAuthn/packages/typescript-types/src/index.ts

  Line 67 in cfa6892

  export interface RegistrationCredentialJSON

• SimpleWebAuthn/packages/typescript-types/src/index.ts

  Line 86 in cfa6892

  export interface AuthenticationCredentialJSON

So long as an RP library conforms to these interfaces they can start using @simplewebauthn/browser's conditional UI today. I won't say these are perfect (I might not have properly nested some values, based on who you ask), but they definitely get the job done right now.

• status code

I'm not entirely sure what you mean by status code here. Are you referring to HTTP statuses? Some kind of indicator/guidance constant indicating what the RP should do next? I've been thinking a lot about the second one lately because I feel my hands are tied as a library maintainer as this is an inappropriate place to include integrations for specific frameworks. I go into that a bit more here: #160 (comment)

• error handling

Is the error identification logic that now exists in @simplewebauthn/browser along the lines of what you're thinking about here?

• https://github.com/MasterKale/SimpleWebAuthn/blob/master/packages/browser/src/helpers/identifyRegistrationError.ts#L7
• https://github.com/MasterKale/SimpleWebAuthn/blob/master/packages/browser/src/helpers/identifyAuthenticationError.ts#L7

[pmlopes]

Hi @MasterKale, what I wanted to say regarding status codes/error handling is more about the "protocol" between the RP and the SimpleWebauthn Client communication. For example, let's consider that a response is sent to an options request from the web client. If the format is incorrect, say there's a field missing, an RP implementation could assume that returning:

HTTP Status Code: 400
HTTP Status Message: Bad Request

Would be enough, as the HTTP semantics tell the client that the request is a user error (4xx status). Although some people would argue that the response should be a valid JSON payload with a well-known format, e.g.:

{ "status": "error", "message": "Input JSON doesn't pass the validation or some better message to the end user!" }

Personally, I feel that HTTP status codes are better to describe this, yet for UI purposes, I can imagine that some descriptive error message should be returned.