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

Compare with Current View Page History

« Previous Version 7 Current »

Summary:

  • IIW Recap
  • DIDComm v2 Hackathon Report
  • Next Steps on AIP 3

Date

(7AM Los Angeles, 10AM New York, 3PM London, 4PM CET, 18H Moscow)



Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.

Attendees                   

Welcome / Introductions

Announcements

Release Status and Work Updates

Discussion Topics


  • IIW Recap
    • DIDComm v2 Interopathon
    • Lots of OpenID4VC sessions 
      • AFJ adding already
    • Bifold and the BC Wallet
      • Lots of Interest
    • AI
      • Trust Issues
      • 'Our' stuff has some of the solution to trust
      • Data more important than the code
      • Previously 'anonymous' data or patterns can be brought to light.
    • KERI
      • New Theme - Security, Privacy, Authenticity, and Confidentiality
    • Trust Registry Discussions
      • Not lots of resolution
    • Low ISO and W3C Topics
    • OWF Sessions
    • Red Teaming Identity - Air Force Research Lab
      • Presentation slides:    
      • Looking for vulnerabilities in libraries
      • Spec where a piece is listed as optional
        • recommend not implementing anything listed as optional
        • a number of vulnerabilities hover around optional features
    • Revocation
    • OCA
    • Government agency interest in the current state of Digital Identity
      • New Legislation, and what should be in it.
      • DHS - hold biometric and biographic repos
  • LF Digital Trust Initiative
    • Potential Container for HL, ToIP, OWF, and DIF
    • Organizational Opportunities for Aries
    • Interested in conversations?
  • DID Peer Update?
  • DIDComm v2.1
  • AIP 3 Next Steps

Not Discussed Notes from last week...

  • DID Peer 2/3 – processing approach – is this the plan:
    • Identifiers:
      • Long Identifier – as defined today, entire encoded DIDDoc in identifier
      • Short identifier is the first 22(?) characters of 64 character string sha256 of long identifier (or something else?)
    • On receipt of a did:peer:3<identifier>, process as follows:
      • Detect length of identifier — short or long (assumption: long peer:did:2 will never be less than 23(?) bytes)
      • If short - resolve DID locally to get DIDDoc - on success, exit
      • If short and resolution failed — error, exit
      • If long
        • Convert long DID to short DID - resolve DID locally to get DIDDoc - on success, exit
      • If long and short DID resolution failed
        • Resolve long DID locally to get DIDDoc — on success, exit
      • if both short and long DID resolution fails
        • If on a “create DID” step (e.g. receiving DID Exchange “request” or “response” or DIDComm 2 new protocol step)
          • Extract DIDDoc from long DID, store short DID and DIDDoc, get DIDDoc — on success, exit
      • Otherwise — error

Other Business

Future Topics

  • Niels Klomp offered a deeper dive into the openid4vc related flows
  • Thomas - Nessus DIDComm 0.23.2 First Release
    • Wallet abstraction for AcaPy + Nessus native
    • Camel Http Endpoint for Nessus agent
    • Support for RFC0434 Out-of-Band Invitation V1 & V2
    • Support for RFC0023 Did Exchange V1
    • Support for RFC0048 Trust Ping V1 & V2
    • Support for RFC0095 Basic Message V1 & V2
    • CLI to work with supported protocols and model
  • State-of-union of Aries projects
  • decorator for redirection after proofs. - existing?

Action items

Call Recording

  File Modified


  • No labels