Code Monkey home page Code Monkey logo

webauthn-ruby's Introduction

Note: You are viewing the README for the development version of webauthn-ruby. For the current release version see https://github.com/cedarcode/webauthn-ruby/blob/2-stable/README.md.

webauthn-ruby

banner

Gem Build Conventional Commits Join the chat at https://gitter.im/cedarcode/webauthn-ruby

WebAuthn ruby server library

Makes your Ruby/Rails web server become a functional WebAuthn Relying Party.

Takes care of the server-side operations needed to register or authenticate a user's public key credential (also called a "passkey"), including the necessary cryptographic checks.

Table of Contents

Security

Please report security vulnerabilities to [email protected].

More: SECURITY

Background

What is WebAuthn?

WebAuthn (Web Authentication) is a W3C standard for secure public-key authentication on the Web supported by all leading browsers and platforms.

Good Intros

In Depth

Prerequisites

This ruby library will help your Ruby/Rails server act as a conforming Relying-Party, in WebAuthn terminology. But for the Registration and Authentication ceremonies to fully work, you will also need to add two more pieces to the puzzle, a conforming User Agent + Authenticator pair.

Known conformant pairs are, for example:

  • Google Chrome for Android 70+ and Android's Fingerprint-based platform authenticator
  • Microsoft Edge and Windows 10 platform authenticator
  • Mozilla Firefox for Desktop and Yubico's Security Key roaming authenticator via USB
  • Safari in iOS 13.3+ and YubiKey 5 NFC via NFC

For a complete list:

Install

Add this line to your application's Gemfile:

gem 'webauthn'

And then execute:

$ bundle

Or install it yourself as:

$ gem install webauthn

Usage

You can find a working example on how to use this gem in a pasword-less login in a Rails app in webauthn-rails-demo-app. If you want to see an example on how to use this gem as a second factor authenticator in a Rails application instead, you can check it in webauthn-2fa-rails-demo.

If you are migrating an existing application from the legacy FIDO U2F JavaScript API to WebAuthn, also refer to docs/u2f_migration.md.

Configuration

If you have a multi-tenant application or just need to configure WebAuthn differently for separate parts of your application (e.g. if your users authenticate to different subdomains in the same application), we strongly recommend you look at this Advanced Configuration section instead of this.

For a Rails application this would go in config/initializers/webauthn.rb.

WebAuthn.configure do |config|
  # This value needs to match `window.location.origin` evaluated by
  # the User Agent during registration and authentication ceremonies.
  config.origin = "https://auth.example.com"

  # Relying Party name for display purposes
  config.rp_name = "Example Inc."

  # Optionally configure a client timeout hint, in milliseconds.
  # This hint specifies how long the browser should wait for any
  # interaction with the user.
  # This hint may be overridden by the browser.
  # https://www.w3.org/TR/webauthn/#dom-publickeycredentialcreationoptions-timeout
  # config.credential_options_timeout = 120_000

  # You can optionally specify a different Relying Party ID
  # (https://www.w3.org/TR/webauthn/#relying-party-identifier)
  # if it differs from the default one.
  #
  # In this case the default would be "auth.example.com", but you can set it to
  # the suffix "example.com"
  #
  # config.rp_id = "example.com"

  # Configure preferred binary-to-text encoding scheme. This should match the encoding scheme
  # used in your client-side (user agent) code before sending the credential to the server.
  # Supported values: `:base64url` (default), `:base64` or `false` to disable all encoding.
  #
  # config.encoding = :base64url

  # Possible values: "ES256", "ES384", "ES512", "PS256", "PS384", "PS512", "RS256", "RS384", "RS512", "RS1"
  # Default: ["ES256", "PS256", "RS256"]
  #
  # config.algorithms << "ES384"
end

Credential Registration

The ceremony where a user, a Relying Party, and the user’s client (containing at least one authenticator) work in concert to create a public key credential and associate it with the user’s Relying Party account. Note that this includes employing a test of user presence or user verification. [source]

Initiation phase

# Generate and store the WebAuthn User ID the first time the user registers a credential
if !user.webauthn_id
  user.update!(webauthn_id: WebAuthn.generate_user_id)
end

options = WebAuthn::Credential.options_for_create(
  user: { id: user.webauthn_id, name: user.name },
  exclude: user.credentials.map { |c| c.webauthn_id }
)

# Store the newly generated challenge somewhere so you can have it
# for the verification phase.
session[:creation_challenge] = options.challenge

# Send `options` back to the browser, so that they can be used
# to call `navigator.credentials.create({ "publicKey": options })`
#
# You can call `options.as_json` to get a ruby hash with a JSON representation if needed.

# If inside a Rails controller, `render json: options` will just work.
# I.e. it will encode and convert the options to JSON automatically.

# For your frontend code, you might find @github/webauthn-json npm package useful.
# Especially for handling the necessary decoding of the options, and sending the
# `PublicKeyCredential` object back to the server.

Verification phase

# Assuming you're using @github/webauthn-json package to send the `PublicKeyCredential` object back
# in params[:publicKeyCredential]:
webauthn_credential = WebAuthn::Credential.from_create(params[:publicKeyCredential])

begin
  webauthn_credential.verify(session[:creation_challenge])

  # Store Credential ID, Credential Public Key and Sign Count for future authentications
  user.credentials.create!(
    webauthn_id: webauthn_credential.id,
    public_key: webauthn_credential.public_key,
    sign_count: webauthn_credential.sign_count
  )
rescue WebAuthn::Error => e
  # Handle error
end

Credential Authentication

The ceremony where a user, and the user’s client (containing at least one authenticator) work in concert to cryptographically prove to a Relying Party that the user controls the credential private key associated with a previously-registered public key credential (see Registration). Note that this includes a test of user presence or user verification. [source]

Initiation phase

options = WebAuthn::Credential.options_for_get(allow: user.credentials.map { |c| c.webauthn_id })

# Store the newly generated challenge somewhere so you can have it
# for the verification phase.
session[:authentication_challenge] = options.challenge

# Send `options` back to the browser, so that they can be used
# to call `navigator.credentials.get({ "publicKey": options })`

# You can call `options.as_json` to get a ruby hash with a JSON representation if needed.

# If inside a Rails controller, `render json: options` will just work.
# I.e. it will encode and convert the options to JSON automatically.

# For your frontend code, you might find @github/webauthn-json npm package useful.
# Especially for handling the necessary decoding of the options, and sending the
# `PublicKeyCredential` object back to the server.

Verification phase

You need to look up the stored credential for a user by matching the id attribute from the PublicKeyCredential interface returned by the browser to the stored credential_id. The corresponding public_key and sign_count attributes must be passed as keyword arguments to the verify method call.

# Assuming you're using @github/webauthn-json package to send the `PublicKeyCredential` object back
# in params[:publicKeyCredential]:
webauthn_credential = WebAuthn::Credential.from_get(params[:publicKeyCredential])

stored_credential = user.credentials.find_by(webauthn_id: webauthn_credential.id)

begin
  webauthn_credential.verify(
    session[:authentication_challenge],
    public_key: stored_credential.public_key,
    sign_count: stored_credential.sign_count
  )

  # Update the stored credential sign count with the value from `webauthn_credential.sign_count`
  stored_credential.update!(sign_count: webauthn_credential.sign_count)

  # Continue with successful sign in or 2FA verification...

rescue WebAuthn::SignCountVerificationError => e
  # Cryptographic verification of the authenticator data succeeded, but the signature counter was less then or equal
  # to the stored value. This can have several reasons and depending on your risk tolerance you can choose to fail or
  # pass authentication. For more information see https://www.w3.org/TR/webauthn/#sign-counter
rescue WebAuthn::Error => e
  # Handle error
end

Extensions

The mechanism for generating public key credentials, as well as requesting and generating Authentication assertions, as defined in Web Authentication API, can be extended to suit particular use cases. Each case is addressed by defining a registration extension and/or an authentication extension.

When creating a public key credential or requesting an authentication assertion, a WebAuthn Relying Party can request the use of a set of extensions. These extensions will be invoked during the requested ceremony if they are supported by the WebAuthn Client and/or the WebAuthn Authenticator. The Relying Party sends the client extension input for each extension in the get() call (for authentication extensions) or create() call (for registration extensions) to the WebAuthn client. [source]

Extensions can be requested in the initiation phase in both Credential Registration and Authentication ceremonies by adding the extension parameter when generating the options for create/get:

# Credential Registration
creation_options = WebAuthn::Credential.options_for_create(
  user: { id: user.webauthn_id, name: user.name },
  exclude: user.credentials.map { |c| c.webauthn_id },
  extensions: { appidExclude: domain.to_s }
)

# OR

# Credential Authentication
options = WebAuthn::Credential.options_for_get(
  allow: user.credentials.map { |c| c.webauthn_id },
  extensions: { appid: domain.to_s }
)

Consequently, after these options are sent to the WebAuthn client:

The WebAuthn client performs client extension processing for each extension that the client supports, and augments the client data as specified by each extension, by including the extension identifier and client extension output values.

For authenticator extensions, as part of the client extension processing, the client also creates the CBOR authenticator extension input value for each extension (often based on the corresponding client extension input value), and passes them to the authenticator in the create() call (for registration extensions) or the get() call (for authentication extensions).

The authenticator, in turn, performs additional processing for the extensions that it supports, and returns the CBOR authenticator extension output for each as specified by the extension. Part of the client extension processing for authenticator extensions is to use the authenticator extension output as an input to creating the client extension output. [source]

Finally, you can check the values returned for each extension by calling client_extension_outputs and authenticator_extension_outputs respectively. For example, following the initialization phase for the Credential Authentication ceremony specified in the above example:

webauthn_credential = WebAuthn::Credential.from_get(credential_get_result_hash)

webauthn_credential.client_extension_outputs #=> { "appid" => true }
webauthn_credential.authenticator_extension_outputs #=> nil

A list of all currently defined extensions:

API

WebAuthn.generate_user_id

Generates a WebAuthn User Handle that follows the WebAuthn spec recommendations.

WebAuthn.generate_user_id # "lWoMZTGf_ml2RoY5qPwbwrkxrvTqWjGOxEoYBgxft3zG-LlrICvE-y8bxFi06zMyIOyNsJoWx4Fa2TOqoRmnxA"

WebAuthn::Credential.options_for_create(options)

Helper method to build the necessary PublicKeyCredentialCreationOptions to be used in the client-side code to call navigator.credentials.create({ "publicKey": publicKeyCredentialCreationOptions }).

creation_options = WebAuthn::Credential.options_for_create(
  user: { id: user.webauthn_id, name: user.name }
  exclude: user.credentials.map { |c| c.webauthn_id }
)

# Store the newly generated challenge somewhere so you can have it
# for the verification phase.
session[:creation_challenge] = creation_options.challenge

# Send `creation_options` back to the browser, so that they can be used
# to call `navigator.credentials.create({ "publicKey": creationOptions })`
#
# You can call `creation_options.as_json` to get a ruby hash with a JSON representation if needed.

# If inside a Rails controller, `render json: creation_options` will just work.
# I.e. it will encode and convert the options to JSON automatically.

WebAuthn::Credential.options_for_get([options])

Helper method to build the necessary PublicKeyCredentialRequestOptions to be used in the client-side code to call navigator.credentials.get({ "publicKey": publicKeyCredentialRequestOptions }).

request_options = WebAuthn::Credential.options_for_get(allow: user.credentials.map { |c| c.webauthn_id })

# Store the newly generated challenge somewhere so you can have it
# for the verification phase.
session[:authentication_challenge] = request_options.challenge

# Send `request_options` back to the browser, so that they can be used
# to call `navigator.credentials.get({ "publicKey": requestOptions })`

# You can call `request_options.as_json` to get a ruby hash with a JSON representation if needed.

# If inside a Rails controller, `render json: request_options` will just work.
# I.e. it will encode and convert the options to JSON automatically.

WebAuthn::Credential.from_create(credential_create_result)

credential_with_attestation = WebAuthn::Credential.from_create(params[:publicKeyCredential])

WebAuthn::Credential.from_get(credential_get_result)

credential_with_assertion = WebAuthn::Credential.from_get(params[:publicKeyCredential])

PublicKeyCredentialWithAttestation#verify(challenge)

Verifies the created WebAuthn credential is valid.

credential_with_attestation.verify(session[:creation_challenge])

PublicKeyCredentialWithAssertion#verify(challenge, public_key:, sign_count:)

Verifies the asserted WebAuthn credential is valid.

Mainly, that the client provided a valid cryptographic signature for the corresponding stored credential public key, among other extra validations.

credential_with_assertion.verify(
  session[:authentication_challenge],
  public_key: stored_credential.public_key,
  sign_count: stored_credential.sign_count
)

PublicKeyCredential#client_extension_outputs

credential = WebAuthn::Credential.from_create(params[:publicKeyCredential])

credential.client_extension_outputs

PublicKeyCredential#authenticator_extension_outputs

credential = WebAuthn::Credential.from_create(params[:publicKeyCredential])

credential.authenticator_extension_outputs

Attestation

Attestation Statement Formats

Attestation Statement Format Supported?
packed (self attestation) Yes
packed (x5c attestation) Yes
tpm (x5c attestation) Yes
android-key Yes
android-safetynet Yes
apple Yes
fido-u2f Yes
none Yes

Attestation Types

You can define what trust policy to enforce by setting acceptable_attestation_types config to a subset of ['None', 'Self', 'Basic', 'AttCA', 'Basic_or_AttCA'] and attestation_root_certificates_finders to an object that responds to #find and returns the corresponding root certificate for each registration. The #find method will be called passing keyword arguments attestation_format, aaguid and attestation_certificate_key_id.

Testing Your Integration

The Webauthn spec requires for data that is signed and authenticated. As a result, it can be difficult to create valid test authenticator data when testing your integration. webauthn-ruby exposes WebAuthn::FakeClient for you to use in your tests. Example usage can be found in webauthn-ruby/spec/webauthn/authenticator_assertion_response_spec.rb.

Contributing

See the contributing file!

Bug reports, feature suggestions, and pull requests are welcome on GitHub at https://github.com/cedarcode/webauthn-ruby.

License

The library is available as open source under the terms of the MIT License.

webauthn-ruby's People

Contributors

8ma10s avatar agchou avatar bdewater avatar bdewater-thatch avatar brauliomartinezlm avatar charlesyeh avatar clearlyclaire avatar dependabot[bot] avatar gitter-badger avatar gogainda avatar grzuy avatar hagould avatar jdongelmans avatar juanarias93 avatar kalebtesfay avatar kingjan1999 avatar lgarron avatar maximendutiye avatar olleolleolle avatar petergoldstein avatar santiagorodriguez96 avatar soartec-lab avatar sorah avatar ssuttner avatar tcannonfodder avatar vuta avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

webauthn-ruby's Issues

Document/suggest how to send ArrayBuffer data

The documentation on this project includes such examples as:

authenticator_data = "..." # As returned by `navigator.credentials.get`

This doesn't make sense on its own, because WebAuthn mostly uses ArrayBuffers to send/receive data, and those can't be sent over the wire and received in Ruby natively like a string or an array. Different applications handle this differently:

https://github.com/cedarcode/webauthn-rails-demo-app encodes from/to ArrayBuffer by mapping the bytes to 8-bit ASCII:

https://github.com/cedarcode/webauthn-rails-demo-app/blob/3afc964edfd3efeb4ad161d4b08a434e8370fd7a/app/assets/javascripts/application.js#L37-L46

https://github.com/duo-labs/webauthn uses websafe/urlsafe base 64 (and hex):

https://github.com/duo-labs/webauthn/blob/fa6cd954884baf24fc5a51656ce21c1a1ef574bc/static/js/webauthn.js#L227-L231

I think either an ASCII string or regular base 64 would be preferable, assuming the former has no compatibility issues with most JSON transports. In addition, it would be nice if there was a way to "directly" read a response from the client, like the load_from_json method in https://github.com/castle/ruby-u2f , since pretty much every client of the library is going to have to do something similar.

So:

  1. Are you willing to stick with a particular encoding suggestion?
  2. Would you be willing to add a convenience method for constructing the AuthenticatorResponse classes from JSON?

Configuration defaults

I think it might be worth considering in the future making RP name and ID configs that can be set just once during boot. While still supporting the override in the #credential_creation_options method.

Originally posted by @grzuy in #155 (comment)

Origin validity check should take into account RP ID (and not `original_origin`)

Right now, this library checks that the origin of the client data of an authenticator response (e.g. a user tap for authentication) is identical to original_origin:

https://github.com/cedarcode/webauthn-ruby/blob/master/lib/webauthn/authenticator_response.rb#L63-L65

However, the original origin of the registration actually doesn't matter. What matters is the RP ID of the registration, although this defaults to the domain of the original origin.

Suppose we are either registering or authenticating at a.b.example.com. Then the default RP ID is a.b.example.com, but the operation may also specify an RP ID of b.example.com or example.com (its "registerable domain suffixes").

So the following are the requirements:

  • The original registration and the authentication must use the same RP ID.
  • The RP ID must be an registerable domain suffix (i.e. ancestor domain that is not a public suffix) of both:
    • the domain used for registration and
    • the domain used for authentication.

If it's still possible at this point in development, I would recommend completely removing the original_origin parameter from AuthenticatorResponse and its subclasses, and just using the rp_id parameter. Unfortunately, I don't have any immediate ideas if you want to maintain backwards compatibility. :-/

Convenience method for loading directly from JSON

[...] In addition, it would be nice if there was a way to "directly" read a response from the client, like the load_from_json method in https://github.com/castle/ruby-u2f , since pretty much every client of the library is going to have to do something similar.

So:

  1. Are you willing to stick with a particular encoding suggestion?

  2. Would you be willing to add a convenience method for constructing the AuthenticatorResponse classes from JSON?

_Originally posted by @lgarron in #79

Macbook TouchID and Android/Chrome support?

According to https://blog.chromium.org/2018/09/chrome-70-beta-shape-detection-web.html Chrome version 70 will support TouchID on recent Macbooks with a Touchbar, and the fingerprint scanner on Android devices. I have only access to the latter at the moment.

I've tried to use my Android device on https://webauthn.herokuapp.com/ but it didn't work. And for some reason after that initial attempt it doesn't show the fingerprint option anymore, on this demo site or the one from Google, which makes debugging hard.

Interestingly enough the Google demo does return "User verifying platform authenticator present" when clicking the "Check ISUVPAA" button on my Android device 🤔

Webauthn FIDO AppID

I would like to use the credentials across multiple subdomains.

As @bdewater mentioned in #92 it would be nice to know how to use the Webauthn FIDO AppID Extension. I do not fully understand how this works but I also found this AppID example.

In the AuthenticatorResponse the rp_id is compared with the rp_id_hash from the authenticator how does this work if you set a FIDO AppID? Should the authenticator pickup the AppID somehow or is this something that needs to be implemented at the RP or can one do stuff on the client to make this work?

FakeAuthenticator API may be a bit awkward to use

We're currently trying to write specs for the callback of the authentication flow and are finding the differences between FakeAuthenticator::Get and FakeAuthenticator::Create a bit difficult to work with. Also, the privateness of the instance variables seems to get in the way as well.

To get some insight, I would suggest attempting to write a test for SessionsController#callback in the webauthn-rails-demo-app.

If you set up the test using attributes from a FakeAuthenticator::Create and then try and test the callback with a separate instance of FakeAuthenticator::Get, they are initialized with a different key and so none of the data signing will be correct.

No implementation to check "attestation type"

leaving this as an issue to note, this is not a requirement from me.

http://w3c.github.io/webauthn/#sctn-attestation-types

There several lines like the following in the attestation statement verification steps:

If successful, return implementation-specific values representing attestation type Basic, AttCA or uncertainty, and attestation trust path x5c.

Maybe returning attestation type from AttestationStatement::Base#valid? could be an interface?

Detect duplicate keys

I took inspiration from your demo application when integrating this myself, and I noticed that I can add the same key multiple times. Is duplicate key detection not supported yet or did I mess something up in my app? If it's not implemented yet, it would be useful to have.

Let pubKeyCredParams be configured

Right now the default is ES256 and RS256, in that order of preference.

Users may want only a subset of those, or want them in a different order of preference.

Split RP ID and Origin validation

AuthenticatorAttestationResponse#valid? and AuthenticatorAssertionResponse#valid? accept origin as its argument, and these methods use it for both RP ID and client data origin validation.

But as you may know, RP ID may be different with origin:

Current interface doesn't allow RP implementation to validate RP ID which is not based on request origin.

Additionaly, unlike maintaining multiple origins for single RP ID, appid extension generates RP ID different from a request origin. If the extension has used in a assertion response, RP ID hash would be generated from https://origin instead of origin. This extension is commonly used for migration from legacy U2F API.

Interface to accept RP ID

I don't make PR now because I want to discuss the interface with you before starting implementation. My idea follows:

assertion.valid?(challenge, origin) # rp_id will be assumed to URI.parse(origin).host
assertion.valid?(challenge, origin, rp_id: 'custom-rp-id')

This interface is good because providing good default for most RP implementation, because RP ID is usually a host part of the origin URL.

WDYT?

Calling #attestation_type before #verify can be confusing

Wouldn't be better for the gem to "just call verification and then return whatever the result was" instead of "returning nil (like saying I don't know)", in case #attestation_type is called before (or even without) calling valid? or verify?

We'll still match the spec. Just easing the ruby gem usage experience.

Originally posted by @grzuy in #122 (comment)

Have thorough test coverage for attestation statement validations

We do have test cases testing that the validation "works" but we need more test cases asserting that the attestation statement verification fails if each of the specific requirements are not met individually.

  • fido-u2f
  • packed / self
  • packed / x5c
  • android-key
  • android-safetynet (moved to #204)

Supporting security keys that were registered using U2F

webauthn allows FIDO security keys to continue to work even if they were registered using U2F. However, if an old registration specified trusted facets using a JSON URL [1][2], webauthn requires using the old AppID URL as the RP ID, with an extension:

navigator.credentials.get({
  publicKey: {
    timeout: /* ... */,
    challenge: /* ... */,
    allowCredentials: /* ... */,
    extensions: {
      appid: "https://site.example/u2f/trusted-facet-list.json"
    }
  }
})

Sites that had significant U2F adoption will pretty much need to plan to handle this permanently. In order to use this library, we're need several modifications:

  • credential_request_options should have a way to specify an appid.
  • AuthenticatorAssertionResponse needs a way to know to use an appid as an RP ID, and use this for URL comparisons and verification of the RP ID hash of the authenticatorData.
  • Many places that assume that the RP ID is an origin (e.g. docs, function parameters) will imply something incorrect in the general case. It would be preferable to keep this accurate, which might require renaming some places to rp_id or such.

Would you be willing to add support for this AppID use case?
If so, do you have any preferences about how to implement it? For example, would you prefer to handle this in AuthenticatorAssertionResponse itself, or in a subclass? Would you like it to be handled to extra parameters for valid?, or maybe a separate function?

I have a fairly non-invasive approach for the verification drafted at lgarron@e748508 using separate validation functions, if you'd like to take a look. However, I'm not happy with the fact that it's a fully parallel implementation rather than a DRY one.

[1] https://developers.yubico.com/U2F/App_ID.html
[2] https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-appid-and-facets-ps-20141009.html

CBOR library choice

Thanks for working on a Ruby WebAuthn implementation. A well supported library will hopefully spur adoption for the many Ruby apps out there today.

I'm curious why you've chosen to use the msgpack based CBOR implementation instead of the libcbor implementation. Knowing very little about either, it seems like libcbor would be preferable. It seems like the msgpack implementation will be difficult to maintain as updates and security fixes are made to the upstream msgpack code. The cbor-ruby Gem has seen virtually no changes since 2016 while the msgpack-ruby Gem is under active development. This seems concerning. In comparison, the libcbor codebase seems more active and easier to maintain.

As I said, I know very little about either project, so the msgpack one might be way better. I'm mostly curious about the thinking behind your choice.

README: Add section that lists supported attestation formats

We're currently in the process of adding support for other attestation formats than none and fido_u2f. I suggest we add a section to the README that states these formats upfront instead of having them browse the code to see which ones have support in the gem.

Pass FIDO2 conformance MakeCredential Resp-1 tests

F-1 Send ServerAuthenticatorAttestationResponse that is missing "id" field and check that the server returns an error

F-4 Send ServerAuthenticatorAttestationResponse that is missing "type" field and check that the server returns an error

MakeCredential Resp-1 tests are mostly about verifying PublicKeyCredential id and type properties when received by the server.

How to run FIDO2 conformance tests: https://github.com/cedarcode/webauthn-ruby/tree/master/spec/conformance.

README: document how to migrate from a U2F implementation

I have no need for this, but I can imagine others will have this question at some point. I think it will be helpful to show how reg.key_handle and reg.public_key from the registration example at https://github.com/castle/ruby-u2f#registration can be used with this gem for migrating an existing U2F implementation.

Icing on the cake would be how to use the Webauthn FIDO AppID Extension as well if a U2F implementation uses an app ID with multiple facets.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.