(meta): action plan 3/15

[rt2zz]

db

• add
  • mode,
  • verified
  • secret to alias
• add mode to session

mode

• For permissions I am currently thinking there are 3 plus the defacto "none": read, write, confirm. Where read is basically login, write is manage aliases, and confirm is 2fa. We can model this as a bitmask a la linux modes.

idWarrant

• add mode and allAlias to idWarrant
• add publicKey to idWarrant

api

• add notifier methods
• add ability for user to get all aliases
  • question: how does this work for 2fa alias where the “credential” is actually a secret seed
    • may need a new column named “confirmSeed” which is never part of public responses
  • how does api look like? can we work this in with onIdWarrant. Perhaps onAuth(idWarrant, aliases)
• store unverified credentials (with verified: false column)
• implement sous-temp core api accessToken
  • something like { idWarrant, roles }

publicKey

do we:

1. lock the publicKey to a session (store in db)?
2. allow publicKey to change on refreshIdWarrant
3. add publicKey on the initial idWarrant, and then after carry the same pub key to each refreshed warrant

[rt2zz]

• add confirmed aliases to session
• hook up publicKey