[DG-BSC] Notes from BSC telecon Tuesday, December 13

Eve Maler eve.maler at forgerock.com
Tue Dec 13 10:34:37 CST 2016



   - 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
      - *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
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

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20161214/33ff44f7/attachment.html>

More information about the DG-BSC mailing list