concept: Tokencontainer

Concept for nested token types (#1291)

Why token-container?

In order to model the physical token representation correctly we need to be able to bundle token together in a container, e.g.

• A YubiKey contains several individual tokens (x509 certs, HOTP-Token, SSH-Key, ...)
• A mobile phone contains several token in an App (HOTP, TOTP, Push, ...)

Several objectives can be achieved by grouping token together:

• Mark all grouped token as "lost" if the YubiKey is lost.
• Require a PIN/FaceID for all token in the App i.e. for opening the App itself (PIN for each individual token already possible)

To be able to handle these containers we need to implement some kind of representation of the container.

Ideas

• Naming:
  • tokencontainer or containertoken?
  • tokendevice
  • tokenreceptacle (Sammelgefäß)
  • token-bin, token-ring (!IBM), token-chain, token-box, token-repository or token-keyring
  • token-pile, token-stack (stacked tokens), token-batch or token-pack
• group tokens / token-types together
• physically connected tokens (One Yubikey contains x509 certs, HOTP-Token, SSH-Key)
• PI should be able to set the PIN/PUK/Admin-PIN of a SmartCard (i.e. through the Yubikey enrollment client)
• nested container:

Implementation ideas

• loosely coupled: each token can have a tag or container-id (like tokengroups)

  Pros:

  • easy to implement (just an additional column in the token table, maybe an additional tokencontainer table)
  • all tokens still work individually like before
  • tokens in a container can still be assigned to different people

  Cons:

  • no container specific functionality (the tokencontainer table could include the container type for specific handling)
  • no assignment of the container to a specific person (each token is assigned individually -> #3124)
  • no multiple level of nested tokens

• token-container inherits from tokenclass

  • all token-specific functionality can be used with the container as well (must be implemented accordingly)
    • validate with one token in the container
    • validate with a specific token (type) in the container
    • mark all tokens in the container as lost
  • similar to the 4-eyes-token/remote-token
  • the container knows its tokens, no need to back-reference the individual token to the container (might come in handy anyway)

• token-container as a separate class

  • easier implementation of multiple levels of nested tokens

API

What functionality should the API provide?

• GET /tokencontainer
  • parameter:
    • user
    • container-type
    • id/serial (to be similar to the /token endpoint)
    • ...
  • returns:
    • list of tokencontainer instances
      • id
      • type of container (class)
      • user of container
      • list of contained tokens
• GET /tokencontainer/{id}
  • returns
    • user
    • type / class
    • list of contained token
• POST /tokncontainer/init
  • parameter:
    • class
    • list of token-serials to add?
• DELETE /tokencontainer/{id}