I'm sorry I missed call on Monday. The new time caught me by surprise and I am at the Identiverse 2018 conference in Boston. Colleagues at US DHS Science and Technology have done extensive research in various aspect of Blockchain including identity use cases. This is ongoing work. You can see more about what they are doing at https://www.slideshare.net/aniltj/blockchain-security-and-privacy Ross On Mon, Jun 25, 2018 at 1:17 PM, j stollman wrote:

Steve,

I enjoyed your perspective on blockchain as a potential solution for IAM.

I especially appreciate your point that the mission of using blockchain for IAM purposes is different from the mission of applying it to the double-spend problem, and that this difference dictates different requirements and yields differences in the resulting solutions for each. This is a point that seems to get lost in the wave of enthusiasm over blockchain which is too often considered synonymous with Bitcoin.

I offer a few comments in response to two topics in your article.

By framing IAM to concentrate on specific attributes in different contexts, we can reduce the accumulation of extraneous information

As I suspect you are aware this statement is an oversimplification. While we might only need a small amount of information to Authenticate that the Alice on the other end of the internet is THE Alice with whom I expect to be dealing, the information required to Authorize Alice to perform various activities may be quite broad. Different applications will require different data. For a payment transaction, the Relying Party will be interested in Alice’s bank balance. For accessing a social network, this information would not likely be required. To set up a doctor’s appointment with a new doctor, Alice may be asked to provide information about her health. While the amount needed for each application may be small, because different applications require different information, the total amount of information required can grow to be quite large.

If any single repository holds all (or most) of this large amount of personal data, it may become a honeypot for hackers. This is because breaking in to this repository rewards them with a wide array of personal information. Thus, our goal is not to reduce the amount of information overall, but rather to reduce the accumulation of authorization data into large repositories.

One obvious solution is to let every Relying Party maintain its own repository that includes only the data it requires to authorize use of its services. But this too has shortcomings. It requires that Alice upload the appropriate personal data to each and every site with for she needs authorization. While this reduces the value of the information stored in any single repository, it creates a wide array of targets – at least some of which are likely to have lax security and be easily penetrated to steal that limited (but potentially valuable) set of data it holds. And from a user interface perspective, it is inefficient. Alice can’t reuse data from a central authorization provider. She has to provide information separately to each Relying Party.

Thus, it is important to separate Authentication from Authorization because they are two different problems. And while blockchain may play a role in either or both, the solutions do not have to be the same.

One special topic in IAM has resonated especially with blockchain concepts – *Self Sovereign Identity* (SSI).

Self-sovereign identity is a noble cause, but does not fully complete the IAM mission. SSI allows Alice to collect third-party claims about her and disseminate them as needed to satisfy the requirements of Relying Parties for authorizing her to access their services. The data (or a link to it) is stored centrally on a blockchain, but is not viewable without provision of a “key” by Alice to the party seeking to view the data. This technique provides Alice with control over the release of her personal information. It also provides a strong linkage between Alice and the data. The data does apply to Alice.

But this solution still leaves open the Authentication step of determine if the Alice for whom the data applies is THE Alice that I believe I am interacting with. In open, public SSI, there is control to ensure that all claims about Alice are provided to me. Perhaps Alice is a scam artist. She has multiple overdrawn bank accounts, each of which she has intentionally associated with different online identities. But in seeking out a mortgage, she may use a different identity associated with another bank account in which she has maintained a large balance for many years. How will the mortgage company every learn about Alice’s bad track record, if she, alone, control what data they can see. All the claims are verified by third parties. But because she controls her identity, we as mortgage bankers can’t be certain that we are seeing all the information that we require to authorize her loan.

--------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Mon, Jun 25, 2018 at 8:59 AM Steve Olshansky wrote:

...

Hi All- Since we are discussing “Authentication with the help of public keys in a Blockchain” I wanted to pass along a white paper that Steve Wilson and I published recently: “Do Blockchains Have Anything to Offer Identity?” I hope you find it useful. https://www.internetsociety.org/resources/doc/2018/blockchain-identity/

Best regards- Steve

-- Steve Olshansky Internet Technology Program Manager Internet Society www.internetsociety.org _______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/dg-idot

_______________________________________________ DG-IDoT mailing list DG-IDoT@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/dg-idot

-- Ross Foard (703) 728-1543 (cell) rfoard@gmail.com