This is the road map for Qvarn software development.

To be finished by end of 2016

  • Make provisioning of a Qvarn+Gluu stack fully automated and share the necessary files with the world.

    • Justification:
      • It is currently quite a lot of manual work to set up a fresh Qvarn and Gluu pair. This takes time and effort, which could be spent on more useful things.
      • Currently few people understand how to deploy Qvarn. That's detrimental to getting more users.
    • Success criteria:
      • A Heat stack for the virtual machines, networking, etc is created. Input: stack name.
      • Software is installed fully automatically on the virtual machines such that Qvarn API tests can be run. This includes creating an OpenID Connect client for test-api. No manual steps are required beyond running Ansible.
      • The Heat and Ansible files we use are published on github, without any secrets (password, ssh keys, etc) we need. The repo includes a README so that others can use the git repo for setting up their own instances.
      • Everyone at QL uses the new repo and automation to set up their own stack for development.
  • Make resource types be configurable via the Qvarn API.

    • Justification:
      • Currently any changes to the supported resource types requires changing Qvarn source code and making a new Qvarn release. This is untenable with many users.
      • Currently Qvarn developers are on the critical path for most Qvarn-using projects, and are often needed for consultation for any resource changes. This takes up too much time from them and is too much of a blocker for others.
    • Success criteria:
      • A freshly installed Qvarn has a minimal set of resource types.
      • New resource types can be added, and existing ones can be changed and deleted via the Qvarn API.
      • Changes to resource types happen immediately: it's not OK to have to restart Qvarn, and it must not be necessary to reconfigure haproxy to implement them.
      • All existing resource types must be implementable with the new way, excluding validation code.
      • Validation code will no longer be supported.

To be finished by end of Q2 2017

  • An automated performance test suite, run regularly by CI, with measurements to identify critical bottlenecks.
  • Make all users in Gluu also have a 1-1 corresponding person resource. And vice versa.
    • This will be needed for "my pages" applications
    • Given a user in gluu, need a link to person resource, and vice versa
  • Support virtual cards.
    • Tie an "electronic card" (app on a smartphone, Yubikey, or similar) to a physical ID card.
  • Support consent management, UMA: subjects need to give explicit consent to every type of use of their data.

Things for which deadlines have not been set yet

  • Add to Qvarn API all necessary calls to manage users, clients, etc in Gluu.
    • e.g., set authentication methods and credentials for users
    • qvarn api clients shouldn't have to understand gluu apis
  • Add API call to get complete and corresponding source code.
  • Make security improvements based on audit. These mainly apply to system configuration, not Qvarn itself.
  • Add an audit log: remote, chain of hashes, digitally signed, encrypted.
  • Support resource version history via the Qvarn API.
  • Rewrite Qvarn ORM to be less painful to maintain.
    • Support automatic database indexing, vacuuming.
  • Change all Qvarn stack nodes to disable unwanted outgoing network access.
  • Add fine-grained ACL for Qvarn API access.
  • Qvarn API: Wildcard listeners for resources.
  • Support contract management, digital signing, transaction verification (possibly via block chains).
  • Expose authentication method used by Gluu in the authentication token given to Qvarn.
    • This is meant to allow authorisation based on the strength of the authentication: username/password might be OK, for some things, but not for mass deletion.
    • This may need to involve some kind of "strength level" definition, e.g., due to eIDAS.
  • Record how a person has been identified during enrolment.
    • Justification:
      • To allow better evaluation of trust for a transaction.
  • Change user authentication to Gluu to be able to specify user by any field (configured by sysadmin) in a person resource in Qvarn, instead of a username in Gluu ldap
  • Make Qvarn logs be privacy-enabled. Also haproxy, uwsgi, Postgres, Gluu.
    • update: Qvarn 0.73 no longer logs all HTTP request and response bodies.
  • Add API call for a dump of all the data about one person.
  • Use CA-signed TLS-certificates for https on all hosts. Possibly using Let's encrypt. This applies to the provisioning recipes QvarnLabs itself uses.
  • Support water stamping, digital signing of data Qvarn returns.
  • Specify, document, publish development workflow, release policy, support structure.
  • Support API versioning.
  • Support monitoring, statistics.
  • Add backup/restore support to Qvarn.
  • Add sensible blob storage to Qvarn.
  • Encryption of the database (store database on an encrypted disk).
  • Encrypted resource fields.
  • Fix the SPOF of the write-only node in Qvarn.