Added new action item for Kevin Griffin to update the New Discussion Items on the main wiki page

News or events of interest to members:

• European Identity Conference is this week
• Identity Week next week
  • https://idnext.eu/event/identity-week-2024
• DICE is in 2 weeks
• Henk van Cann - ToIP Terminology Breakthrough
  • Added the ability to version terms in the wiki and make references to specific versions that will be long living.
  • Preview of how it works:  https://dwarshuis.com/test/spec-up-xref/docs/

    • look at the terms ‘agent’ and ’biometric’

• Specifications
  • CESR - Sam Smith pushed changes with RFC 2119 changes (MUST/SHALL).  Please Review!
  • KERI and ACDC Spec 2119 specs on their way
• KERIpy
  • Kevin Griffin  
    • Bug fixes / rename issues
    • Updated the Dockerfile to fix issue with Alpine
    • Updates for ReadTheDocs
    • Started working on upgrades to databases in basing
  • Philip Feairheller 
    • PR coming with externalized payloads of EXN messages as attachments
• KERIA
  • Lance Byrd - New PR for delegation approval
    • Philip Feairheller to review

• FIDO2 Integration
  • Likely resulting from conversations around did:tdw
  • did:tdw using just pre-rotation does not protect you against "dead attacks"... compromised stale key or malicious controller
    • The only thing that protects against dead attacks is control over the URL that publishes the did doc
      • This means that did:tdw is no more secure than existing web infrastructure. 
    • The mechanism to protect against dead attacks is provided by KERI with Witnesses and Watchers and anchored data.
  • The conversation led to "isn't it better to use some of KERI to get more secure PKI" and provide more adoptability
    • Conclusion:  If you want simple PKI that is more adoptable, why not just use FIDO2?
  • FIDO2 signs data and therefore is more secure than TLS that uses encryption for authentication
    • The weakness of FIDO2 is key rotation.
  • KERI solves the following hard problem:
    • "Can I maintain control over a persistent identifier despite key compromise"
    • This assumes key compromise.
      • If you don't care about key compromise (assumes PKI is strong enough) than you don't need KERI
  • Henk van Cann - Some folks may want to make the trade off of assuming PKI is "enough"
    • Sam Smith for standards bodies that are creating specifications for "Trust", making this assumption means that you are forcing this assumption on everyone that wants to use this spec.
• Mini-Conference on first day (June 18th) at DICE in Zürich
  • Proposal from Henk van Cann 

  • 1. Answers to questions from EU Digital identity service providers tendering ARF: https://github.com/WebOfTrust/WOT-terms/issues/159 ; who: Henk after curation

    2. KERI Suite introduction: vision, team, code, governance, implementation ; who: Henk

    3. How to get started with education about the KERI Suite ; who: Henk

    4. Why has KERI been build the way it is?  ; who: Henk (hopefully Sam there to correct)

    5. KERI’s Killer Security features and scalability; who : Sam?

• Kent Bull is there any use for using a DID Doc with KERI?
  • Could a DID Doc be used to communicate information about issues or verifiers?
  • Sam Smith only makes sense to use DID Doc in the context of standard DID resolution.  

• Kevin Griffin add action items to top level Wiki page
  • Topics for discussion
    • User Experience
      • OOBI exchanges
    • Watcher Network
    • Fido2 integration
    • Where to store rotation keys?  From meeting chat:

      "we don’t have a recommendation about storing and generating pre-rotation keys. If we are generating and storing pre-rotation keys on same system that is generating signing keys, and if an attacker can compromise signing keys, the attacker can very easily compromise rotation keys as well"

    • Sam how would we explain the fact that even when not using a Blockchain system keri still introduces other components such as jurors and watchers to solve the duplicity detection problem that just appears because of the need of more than just the principal of the entitiy? IMHO it seems like we still need to trust others to avoid bad actors. What is more to make it more available we are still using components to expose the KELs of entities. Meanwhile blockchains solves it inherently at the expense of ledger locking.