Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »


Conceptual things to think about

  • Only support for the authentication ceremony
    • Registration ceremony is handled elsewhere, out-of-band e.g. using Privacy Idea, or something else.
    • Need a standard way to retrieve the registered credentials;
      • or ask the party responsible for registration to generate a CredentialRequestOptions for the authentication ceremony to proceed, and ask it to validate the resulting assertion. 
  • Support for 'single-factor and '2nd-factor' experiences?
    • Statically configured, or determined at runtime:
      • This depends on the 'type' of authenticator you have e.g. does it support single-factor webauthn (supports UserVerification) or just 2nd-factor (only supports UserPresence)
    • Also, requires the authentication request (CredentialRequestOptions) to signal that requirement - easy enough if we control the creation of that, but not if we delegate to say PI?
  • Support for usernameless in addition to passwordless. Depends on Credential Storage Modality.
    • Passwordless requires an initial username input step, and key material can be stored IdP side - not on the authenticator.
    • Usernameless requires the authenticator to store the public-private key pair, in addition to a user handle specific to that origin (site). Also know as a resident key or discoverable key. 


Technical things to think about

  • A pluggable way to create an authentication request (CredentialRequestOptions).
    • A call to PrivacyIdea.
    • An interface to 'local' public key attributes e.g. using the attribute resolver like the TOTP plugin
      • Probably using the Yubico libraries to generate the request
      • Although, the 'signature count' is mutable and may!? need writing back somewhere - need to check the spec.
    • From an AJAX request or SWF action and page navigation.
  • A pluggable way to verify the credential assertion response
    • A call with the JSON assertion response to PrivacyIdea
    • Using the locally resolvable attributes and a suitable internal library (Yubico works well) to verify the response i.e. abstractly, the signed assertion can be verified with the public key.
  • Storage
    • PublicKey in COSE format - fixed once registered
    • A credential ID - fixed once registered
    • A user handle (the same one for each key for a given user). - fixed once registered
    • A signature count. - can mutate during authentication.
  • If we use PI, do we make a generic integration library for it (or does it have a Java SDK, check) and just use that with the possibility of using more of its auth methods in the future.


  • No labels