Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Summary:

Excerpt

Planned Topics:

  • Getting to release 0.7.4
  • Aries Endorser Service – a new repo Ian Costanzo
  • Connections and Authentication in Aries

Recordings from the call: 

  • Full Meeting: <To be added> 20220503 ACA-Pug Community Call Recording.mp4
  • Extracted segments: 
  • Chat: 
    • 08:24:10 From Timo Glastra : In addition to the allow list for connections, having an allow list for dids would also be useful (in an application we're building we do it based on did)

    • 08:29:51 From Colton Wolkins : Will take a deeper look into what's there and what the requirements currently are. Thank you for starting the project!

    • 08:34:12 From Colton Wolkins : My biggest concern with authentication is a problem that Discord has with their QR Code system. I look forward to see how everything pans out in the future

    • 08:41:07 From Paul Wenzel : https://github.com/hyperledger/aries-cloudagent-python/issues/1743

    • 08:46:09 From Fabio Tagliaferro : The JSON-LD Credentials in ACA-Py tutorial lacks the Present Proof section https://github.com/hyperledger/aries-cloudagent-python/blob/main/JsonLdCredentials.md#present-proof
      In case, I would be happy to contribute to improve the tutorial with the missing section

      This could be an alternative to follow https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/AliceWantsAJsonCredential.md
      But I found it confusing with some endpoints that I cannot find in a non-demo ACA-py agent
      Namely: /issue-credential-2.0/send-offer and /request-presentation-2.0/request-proof

      In the meanwhile, could you please link some useful resources to use the BBS+ credential for a verifiable presentation?

    • 08:51:29 From Colton Wolkins : I'm not 100% certain if revocation entries are endorsed ATM. I'd have to double check

    • 08:53:10 From Ian Costanzo : It’s configurable by ledger

    • 08:53:48 From Ian Costanzo : By default the tails file location and the original accumulator has to be endorsed, but when crews are revoked and the updated accumulator is written that doesn’t need to be endorsed

    • 08:54:03 From Wade Barnes : Currently on most networks rev_reg_entries do not need to be endorsed, however there is nothing stopping a network from enforcing the rule, so we've decided to have the ability to send all transactions through an endorser.

    • 08:54:29 From Colton Wolkins : Right x3

    • 08:55:01 From Colton Wolkins : I just don't remember seeing signatures on the Revocation records the last time I was playing with Author/Endorser


Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.

Welcome and Introductions

...

Announcements

Deployments and Work Updates

...

  • Getting to release 0.7.4 – what is needed after RC1
  • Aries Endorser Service – a new repo Ian Costanzo
  • Connections and Authentication in Aries
  • Dealing with the issues of a failure to access a tails server when needed
    • For provers – they can cache the tails file to reduce the need to contact the tails service
    • For issuers it's trickier as you (currently) have to write the ledger transaction and then upload the tails files
      • If you can't write to the tails file, it's too late.
      • Per @ianco Best thing to do is write the tails file first, then write to the ledger.
        • Further mitigations – use multiple tails file servers and fallback to other ones when needed.
        • Even possible – when a tails file write fails, host the tails file on the ACA-Py instance – and let the site Admin know that was done...
    • Other solution – replace the current revocation method with a new one that doesn't need tails files...

Next Meeting

Future Topics

...