http://kantarainitiative.org/confluence/display/BSC/2016-12+%28December+2016... Agenda: - Report work and recommendations Attending: Eve, Matisse, Thomas, Susan, John W, Colin, Kathleen Symbiont spoke at the NAIC conference yesterday about identities (corporate exclusively?) and smart contracts. This relates to beneficial ownership. We appear to be on the cusp of this being figured out because of the pressure from corporations, at least. So it may behoove us to make recommendations about natural-person identity work regarding several efforts, e.g. several WGs in Kantara. Susan also attended the Smart Contract Alliance event this past week, where there were three regulatory agencies represented, speaking about how things might work for them. Personal identities are going matter to them, but they have no concept of this – they just know about KYC (Know Your Customer) in a regulatory sense. "If you want universality, it must be imposed by some external standard. If you want autonomy, you must recognize individual choice. These two are in some sense antithetical." If something like Sovrin is widely adopted, Eve suspects its uses would devolve to KYC-type use cases. We could essay some of these principles (and oxymorons?) in our intro. There are no silver bullets in "self-sovereign identity". Microsoft announced that Dan Buckner is forming a unit around something similar. Thomas notes: It's all about the data, and who has control over it. Is it considered a joint asset or not? A concept called the LLP – Limited Liability Persona – used to be floated (by Bob Blakley? Burton Group folks, at any rate). Some banks do seem interested in giving their individual customers control over releasing their own KYC data in personal data store-like fashion, DLT or no. In terms of the logical choices of where to store a person's PII: - *Traditionally:* Attributes have been stored in something like a directory server, more "voluminous" records (e.g. EHRs) might be stored in something like a CMS, and other databases such as RDBMSes might be used for other personal data. Organizations in charge of collecting and generating this data are by regulation, profit motive, and custom responsible for managing its security and data protection. - *With DLTs in the picture:* Other options become available: - *Public ledger:*Conventional wisdom has already formed, it seems, that you don't put PII on a public ledger. The reasons are: bloat, distributedness, and consumer management of private keys. The two other options given this are: - Pointers from the public ledger to other traditional server-side storage (a la Blockstack, in presumably most implementations?) - Pointers from the public ledger to client-side storage (a la Sovrin) - *Private ledger:* This can be secured by any traditional means, so it doesn't suffer from the weaknesses of the public ledger approach. AI: Eve and Thomas: Put the above text in the draft report. There's an interesting challenge with allowing people to *control access/permissioning* as the primary goal vs. allowing people to *control personal data* as the primary goal. Client devices are generally not meant to be running all the time (e.g. to serve relevant data), whereas a transaction (such as making a payment) generally requires that a service be up and running. Imagining that a person's mobile device is a storageless UMA authorization server that can access what it needs in the cloud and makes a callback, would that work if a requesting party Bob tries to access Alice's resource? *Next time:* Craft scenarios that aim to maximally empower a person (possibly choosing one or more of those that appear in these notes http://kantarainitiative.org/confluence/display/BSC/2016-11+%28November+2016..., but try not to be too UMA-specific!), and work on setting forth the requirements for DLT- and other-related technologies that they'd have to meet in order to meet our DG's goals for transactional empowerment of individuals. *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl