Versions Compared

Key

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

...

Rohit Shitre - Working with AyanWorks as a blockchain developer. Working on HL Indy. 

Tony Bellan

Recording

audio

video

Minutes

Anti-trust Policy and Code of Conduct

...

Perhaps as simple as no private information on the blockchain, including private DIFs. What is the scope of the conversation

PII not on blockchain? How to localize? How to access by authorized parties? Not only PII that is protected - transaction information, metadata. 

Privacy - personal data - laws are in place - privacy protection and comply with GDPR. Conversation is separate - privacy or privacy on blockchain.

What about correlating with transactions? Then poor design. Scope of DLT - if audit transactions on the ledger - can't be pseudo anonymously identifiable. 

The ledger becomes pure proofs? Yes. Hashes? Workgroup 29 EU GDPR - encrypted data should not be put on chain. Hashes or salted hashes, maybe? Privacy lawyers? Reverse engineer? Gray area - don't do it. Don't put hashes of PII on-chain. 

Other systems will do PII storage and identity proofing? Identity management systems, covered ISO 307. Security and Identity management systems. 

Safe? Not according to the news. Perhaps insider threats or poor implementation. Not a DLT thing unless you scope it into the conversation. DLT is a system of records somehow. CORDA is a bilateral system, visible to parties on transaction, not others. 

Right of erasure? How do you remove? Direct impact on adoption of adoption of a particular ledger.

Focus - what is written to the ledger, including transaction audits. And, what should transaction audits be comprised of? Transaction audits to PII? In India or CORDA conversation - if implemented based on based practice - pairwise pseudo channels with service requestor and service provider. Only those two know - like FIDO - you can have a different DID - thousands of private DIDs for one service provider? How do we have privacy protection on the ledger? 

Have to expose data to verifier? Verifier has the right to copy the data? As service provider. You can de-link Issuer from Verifier. On the ledger will be whatever available to make pairwise DID conversation more private. In the end, the Service Provider is capturing data and associating it with a person. The doctor knows who you are. 

How do you protect on-chain in a DLT. As soon as I give a pairwise pseudo-anonymous channel - we're off-chain and in a different domain. That's any Identity management domain. Rife with leak problems.


Image AddedImage Added

Image Added

Certain headings, if you go to Consumer Rights and Business Obligations - all are present in one form or another. Some laws do not protect certain items. Say all going to be implemented in Identity and Access Management Systems and we are the 'glue'. 

If a customer wants access to collect data and ask for it - lots of ideas with cryptography, zero knowledge proofs, etc. Need to discuss what is stored and not in the ledger. Do we need a ledger? The accumulator and transaction audits. The accumulator keeps track of valid verifiable credentials and revoked verifiable credentials.

SSI - what is the latest state of DIDs and SSI technology including Indy, Aries, and other associated. 

End of meeting.