Page Comparison

Summary:

...

06 Mar 2024 (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

• Sam Curren  (Indicio) <sam@indicio.tech>

Welcome / Introductions

Announcements

• IIW - April 16-18

Release Status and Work Updates

• Aries Agent Test Harness -- https://aries-interop.info
• Aries Shared Components - Indy SDK replacements
  • Indy Verifiable Date Registry - Ledger Interface https://github.com/hyperledger/indy-vdr
    • PR merged for caching in Indy VDR of Pool Transactions - Aries Frameworks should be adding that to
    • Release 0.4.0
    • Release 0.5.0 will have breaking changes, including did:indy branch merged into main.
  • Aries Askar secure storage - https://github.com/bcgov/aries-askar
    • Release 0.2.9
  • AnonCreds Rust - https://github.com/hyperledger/anoncreds-rs
    • Release 0.1.0
  • Shared Rust Library/CredX (AnonCreds) https://github.com/hyperledger/indy-shared-rs - being replaced by AnonCreds Rust
    • Release 0.3.3 Bugfix (bug was in the python wrapper)
      
    • Release 1.0.0 Embeds new AnonCreds CL Signatures library with fixes, performance improvements
• Frameworks:
  • Aries-CloudAgent-Python https://github.com/hyperledger/aries-cloudagent-python, Meetings: ACA-Pug Meetings, Documentation: https://aca-py.org
    • 0.12.0rc0 – Peer DID support, many enhancement/fixes, nothing breaking yet but at least one will be made before finalized.
    • Release 1.0.0 Checklist has been created and is being worked on.
    • Traction Sandbox now available - https://traction-sandbox-tenant-ui.apps.silver.devops.gov.bc.ca
      • Workshop Tutorial for using Traction, AnonCreds and Aries 
      • Repo - https://github.com/hyperledger/aries-acapy-controllers/tree/main/TractionIssuanceDemo
  • Credo (Agent-Framework-JavaScript)  https://github.com/openwallet-foundation/credo-ts, Meetings: Credo Meetings
    
    • 0.5 in the works
      • Dropping IndySDK
      • AnonCreds Revocation
      • Dropping Node 16 support (EOL)
      • W3C issuance and verification of AnonCreds credentials
      • did:peer:2 and  did:peer:4 support and did rotate protocol
    • Continuing working on SD-JWT and OpenID4VC support
  • Aries VCX (https://github.com/hyperledger/aries-vcx, Meetings: Aries-VCX Meetings
    
    • aries-vcx as repository now contains 2 project families:
      
      • aries
      • didcore
  • Picos as of pico-engine version 1.3.0 natively use DIDComm v2 (https://github.com/Picolab/pico-engine/blob/master/packages/pico-engine/README.md)
    • replacing ACA-Pico agents (https://github.com/Picolab/aries-cloudagent-pico) which are now deprecated
    • protocols implemented so far: oob invitation, trust-ping, basicmessage (more to be added https://github.com/Picolab/DIDComm-V2)
    • based on the SICPA didcomm NodeJS module
  • Aries-Framework-Go (Troy) #aries-go (https://github.com/hyperledger/aries-framework-go, Meetings: aries-framework-go) 
• Mobile:
  • Aries Mobile Agent React Native, aka Aries Bifold https://github.com/hyperledger/aries-mobile-agent-react-native, Meetings: Aries Bifold User Group Meetings
    • 0.4.0 in Bifold – including the shared components
  • Aries-MobileAgent-Xamarin aka Aries MAX (https://github.com/hyperledger/aries-mobileagent-xamarin)
• aries-mediator-service – a DIDComm Mediator in a Box
  • Update to use SocketDock?
• aries-endorser-service – an Indy Endorser in a Box (in development)
• Aries Akrida - Load Testing DIDComm based protocols
  • Added module support for different Issuer and Verifiers

Discussion Topics

• Fabric Ecosystem docDiagram / Document - David Boswell
  • Fabric Ecosystem ecosystem
  • We need one for Aries
    • Sam will make a wiki page.
• Credential Protocols for DIDComm v2
  • https://identity.foundation/waci-didcomm/
    • https://github.com/decentralized-identity/waci-didcomm/blob/main/issue_credential/README.md
    • https://github.com/decentralized-identity/waci-didcomm/blob/main/present_proof/present-proof-v3.md
  • Wishlist / Goals?
    • (all assigned)
  • Done / Almost Done
    • Features that may not be necessary - patrik
    • reverting .1 and .2
    • Removal of any reference to payments.
  • DIDComm v2 conversion
    • Smaller changes may mean faster adoption
    • negotiation pulled out into a sibling protocol - (nobody using negotation? Subhasis referenced use.)
      • propose message moves to different family.
    • Document the short-circuted use of the protocol that starts at issuance directly, depending on needs of credential type.
    • we need to be careful not to match protocol to UX human steps on a 1 to 1 basis
    • abandoned state - if a user declines to present, what should happen between the holder and verifier?
      • problem report sent (or no message, see below) on decline - should be documented
    • offers that sit for a long time at the holder
      • documenting a timeout for the offer.
      • use of timing in thread decorator
    • Removal of any reference to payments.explicit 'no' messages instead of a problem report when it's an explicit no, instead of an error.
    • document use of timeout for offers (didcomm v2 friendly, perhaps a field within the protocol.
  • After DIDComm v2 conversion
    • return of supplements
      • credential chains
      • OCA / ux
      • needs a re-think
        • hashlinks
        • signatures?
    • different protocols for different credential types? (needs discussion)
      • make sibling protocols for each credential type instead of being universal?
    • preview model doesn't work for vc data model creds. could allow an unsigned version of the credential being issued.
    • nobody using negotation? Subhasis referenced use.
    • cred def reference - did:indy and language that makes clear DIDs can (should?) be used.
      • requirements for DID methods that resolve to cred related assets
    • return of supplements
    make sibling protocols for each credential type instead of being universal?
  • Deferred / Maybe NeverAfter DIDComm v2 conversion
    • Different protocols for different sections?negotiation
      
      • offer/request
      • actual issuance
      • ui note
        • we need to be careful not to match protocol to UX on a 1 to 1 basis
  • DIDComm v2 conversion
    • Smaller changes may mean faster adoption

Other Business

Future Topics

...