...
- Name (Organization) <email>
- Robert Mitwicki Robert Mitwicki(The Human Colossus Foundation)
- Mike Richardson ( EuroLedger) <emerysolutions@yahoo.co.uk>
- Stephen Curran (Cloud Compass Computing Inc.) <swcurran@cloudcompass.ca>
- George Aristy (SecureKey) <george.aristy@securekey.com>
- Steve McCown (Anonyome Labs) <smccown@anonyome.com>
- Ed Eykholt (iRespond) <edeykholt@irespond.org>
...
- Substantial update since the last version
- Chained credential solves the delegation problem but that is not the only one
- There is no specific requirements to change anything in the VC spec at all. is just about adopting convection
- VC are head for a problem - same problem as the certificate authorities at the beginning of the web, this what we are trying to avoid is to keep the list of all trusted parties. Instead of small list of entities to trust and cover whole space.
- If everyone can be issuers, the problem appears how to keep truck who I can trust.
- Data provenance → side the sources into VC
- We need clever way to do the revocation (wip)
- logic in verifier code is needed to support chained credentials
- how nonce is used in embedded proofs:
- verifier checks old nonce to verifiy that this happened in the past
- Does I have to disclose privacy by just letting someone walk up the history upstream of the credentials?:
- ZKP veriants and their privacy implications
- Cross correlation through multiple use - offline
- Anonymous of the entities in the chain can be achieved.
- Late and strong anonymity - is up to the case
Aries toolbox
- base Intention: "Postman" for Agent - to help developers to develop agents.
- Development tool
- Administrator tool - to control the agent
- Demo purposes
- UI module - corresponds to one or more protocols in the backend
- Discussion will be continued on the Call B .
RFC Progress
Other Business
...