[DG-BSC] Fwd: Questionnaire for the Sovrin Foundation for the BSC report

Eve Maler eve.maler at forgerock.com
Fri Dec 2 16:01:56 CST 2016


Latest sets of answers on Sovrin, after Thomas and I sent followup
questions. See answers from both Andy Tobin and Drummond Reed.


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

---------- Forwarded message ----------
From: Andrew Tobin <andrew.tobin at evernym.com>
Date: Tue, Nov 29, 2016 at 1:35 PM
Subject: Re: Questionnaire for the Sovrin Foundation for the BSC report
To: =Drummond Reed <drummond.reed at evernym.com>, Eve Maler <
eve.maler at forgerock.com>, Phil Windley <phil at windley.org>
Cc: Thomas Hardjono <hardjono at mit.edu>


Hi Eve - great questions. I'll chuck in a few additional answers but can't
put them inline as my email client is uncooperative.

- Correlation. Phil has nailed this. Pairwise identifiers for each
relationship means that correlation/collusion is minimised. Obviously if
you reveal to a relying party three proofs of name and address from three
different providers, they will be able to see your relationship with those
three providers (a bit like taking 3 physical name/address utility bills to
a bank for example). But there's no way they'll be able to correlate these
with a different relationship you have with an online betting company for
example.

- Right to be forgotten/deleted. This is a really interesting one which is
quite easy/obvious when you think about it. You won't be storing personal
info on Sovrin - you'll keep it in a vault off-ledger. So if you want to
delete it, just delete it. Even better, you'll have a record of every
organisation/person that you shared info with (via link contracts or
consent receipts) which will be anchored to Sovrin. You can then submit
"delete" requests to those orgs, with the original consent receipt as proof
that they have your info. You can then, if you wish, audit those orgs to
confirm that they have complied with your request (this audit/check is
nothing to do with Sovrin other than using Sovrin to prove that you shared
data with them in the first place and asked them to delete it).

- Data controllership. I'll assume you mean something along the lines of
whether the issuer of a claim (like a driving license authority) has any
control over that claim once it has been issued. The answer is that they
can revoke it if they wish. A driving license is an interesting example. If
I get banned for drinking & driving, it's only my entitlement to drive that
is revoked. My name, address and DoB stays the same. Sovrin revocable
anonymous verifiable claims allows the issuer to revoke one aspect of a
claim (entitlement to drive), leaving the other attributes alone,
anonymously i.e. Nobody can ping some sort of revocation list to see if
your license is revoked - only you can enable them to do this when you
provide proof of that claim. Once the issuer has given you the claim, it's
yours, aside from the revocation piece. A relying party may elect to demand
proof of address less than 3 months old for example. If your proof of
address is 6 months old, you'd be able to re-request that proof from your
issuer and get another more recent one - you can do this as you have a
relationship with that issuer already and they know who you are (via
pairwise distributed identifiers that they issued the original claim to you
with, and only you can re-request that claim).

- Non-individual entities. Sovrin handles identifiers for people,
organisations and things. Every entity has one or more DIDs on Sovrin. An
organisation like a bank may just have one DID. Within that DID is a DID
Descriptor Object (DDO) which contains details that the DID owner is happy
to make public (e.g. Public key). A bank would probably want to add their
name, address, and reputation information to their DID so it is possible
for all to see it. No need for any other system - the DID is a superb way
to handle flexibility across different types of identity. The beauty of it
is that Sovrin enables a totally distributed way of handling public keys
and identifiers with no need for a central authority, so anyone/anything
can have one or more DIDs. The latest DID spec is here and is worth a read:
https://github.com/WebOfTrustInfo/rebooting-the-
web-of-trust-fall2016/commit/6e8b0c36b178ac2c643ebdea5c15f10074d12aee
- IDPs. IDPs can still be IDPs. In fact I'd say that they are vital to any
identity ecosystem. What Sovrin can do is massively increase the
portability of an ID proof that an IDP creates. By writing the proof to the
individual's Sovrin identity, that individual can then use it anywhere they
want. If you look at GOV.UK Verify for example, or eIDAS, the valuable
thing is the fact that the IDP has proven your data to LoA2 under the UK
Government's proofing policy. At the moment, that proof is only usable in a
very small ecosystem. To expand that ecosystem you need to add lots more
orgs to the hub that the UK govt has built, bringing issues around
unacceptable correlation & collusion. Plus the problems of scaling up a
fairly rigid hub model. Plus the problem of adding a new identity
transaction (e.g. proof you are a doctor) to that hub, which could take
months/years. With Sovrin, there's no hub so you get massive scalability
and the flexibility to add new data/claim types at will with no dependency
on anything else. So for GOV.UK Verify, it would be very interesting if the
IDPs wrote their users' proofs to their Sovrin IDs (and/or acted as the
initial trust anchors to sponsor those individuals onto Sovrin), which at a
stroke would increase the usability of Verify many-fold with no new hubs
etc.

Hope that helps!

Andy

Andy Tobin
Managing Director, Europe
Evernym
andrew.tobin at evernym.com
+44 7710 761829 <+44%207710%20761829>

On Tue, 29 Nov 2016 at 21:36, Phil Windley <phil at windley.org> wrote:

> Thanks Eve.
>
> I’m looping in Andy Tobin and Drummond Reed. I’ll put a few answers below,
> but they will probably have other, better ones. :)
>
>
>
> On Nov 26, 2016, at 3:22 PM, Eve Maler <eve.maler at forgerock.com> wrote:
>
> Hey Phil! Hope you're doing well. Cc'ing Thomas here... Based on BSC group
> discussion over the past few weeks, and reviewing the Sovrin materials,
> Thomas and I put together a few followup questions on Sovrin for you and
> Andy. Thanks very much in advance for any thoughts in response...
>
>
>    - In the Sovrin vision, how is the challenge of big data inferences
>    and data fusion seen -- that is, the effects of correlatability in the face
>    of sharing small amounts of data (sometimes just behavioral)?
>
>
> Sovrin doesn’t address the correlation of data except where that data is
> identity data specifically linked in Sovrin. Sovrin allows identity owners
> to create unique DID (digital identifiers) for each relationship to avoid
> correlation via those identifiers. Of course, of the identity owner then
> shares a mobile number with two orgs, they can correlate with that. That is
> outside the scope of Sovrin.
>
>
>
>    - How would “right to erasure”/”right to be forgotten” requirements be
>    managed?
>
>
> Identity owners typically interact with Agencies, organizations that
> provide identity services to identity owners, run policy engines on their
> behalf, etc. They would have a right to be forgotten in so far as those
> agencies had jurisdiction in countries that required it and had identifying
> data on them (account information).
>
> Data written to the ledger itself is not erasable. It can be revoked, but
> the original data on the ledger remains. However, as a general rule, the
> data written to the ledger is not personal identifying. Best practice is to
> write that into an appropriate data store and reference it from the ledger.
> So, deleting it where it lives would delete the data but not necessarily a
> record that it existed.
>
>
>    - Thinking of IdPs “becoming identity proofers”, Is it correct to say
>    that a former IdP would become a Sovrin steward in an issuer role and would
>    do proofing as part of provisioning, or is there some further role for
>    former IdPs?
>
>
> Not necessarily a Steward. There will be relatively few Stewards (around
> 100). Stewards run the nodes the record transactions on the ledger. A
> separate Agency function provides DID issuance services, policy services,
> and identity data management. One of the purposes of an Agency (see The
> Inevitable Rise of Self-Sovereign Identity) is to provide storage for
> off-chain assets.
>
> https://www.sovrin.org/The%20Inevitable%20Rise%20of%
> 20Self-Sovereign%20Identity.pdf
>
>
>
>    - Is there a notion of “data controllership” (the privacy concept),
>    where an online service has an interest in and accountability for the data?
>    How does this fit with plans for the forthcoming Sovrin Steward Agreement,
>    regarding both issuers and readers?
>
>
> Drummond? Andy?
>
>
>    - Is it anticipated that the Sovrin economic model (and/or something
>    else) protects against reputation and trust anchors being susceptible to a
>    Sybil attack?
>
>
> This is an active area of discussion. Drummond has an entire Google Doc he
> can share.
>
>
>    - If there’s some rival but similar identity ecosystem with its own
>    issuers and readers, would the ecosystems have some way to interoperate?
>
>
> Yes, that’s the point of Digital Identifiers (DID’s) and DID Descriptor
> Objects. Drummond probably has more here.
>
>
>    - What about storing data about, and controlling access to,
>    non-individual identities, such as smart things, enterprises, or
>    applications? Would those just use different systems?
>
>
> Sovrin is designed to be used by individuals and organizations to manage
> identities for themselves and all the things they care about. There’s no
> reason Sovrin couldn’t be used for the IoT, but those identifiers and
> associated data would belong to the person who owns the things. Identity
> owners (people and organizations) can create as many DIDs as they need to
> for whatever purposes they have.
>
>
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter:
> @xmlgrrl
>
> On Sun, Oct 23, 2016 at 5:04 PM, Phil Windley <phil at windley.org> wrote:
>
> Cool. Appreciate the opportunity to contribute. If you need attribution,
> that was from Andrew Tobin.
>
> Have fun this week. Talk soon.
>
>
>
>
>
> On Sun, Oct 23, 2016 at 5:42 PM -0600, "Eve Maler" <
> eve.maler at forgerock.com> wrote:
>
> Belated ack/thanks for this! I'm going to send it to our DG for question
> and comment as we work through it. What we publish may be a combination of
> quoted sections, paraphrases, commentary, and so on, and since we do our
> work in the open anyway, of course we'll invite and welcome comment back on
> the draft.
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
>
> *The ForgeRock Identity Summit* is coming to
> <http://summits.forgerock.com/> *Paris in November!*
>
> On Fri, Oct 14, 2016 at 8:30 AM, Phil Windley <phil at windley.org> wrote:
>
> Here’s some answers to the questionnaire. Let me know if something doesn’t
> make sense or needs more explanation.
>
>
> *Deficits and benefits of how the problem space was/is being solved*
>
> The Internet was built without a standard, explicit way of identifying
> people or organisations. So websites simply began offering their own local
> accounts with usernames and passwords, and this has been the predominant
> solution ever since.
>
> But the Internet has expanded hugely, and people use more and more
> services daily. This silo-based approach, where users must maintain
> identities for every site they interact with, has become untenable. It is
> not just a usability disaster for individuals, it also creates a multitude
> of data honeypots for hackers—the breach of which compromises trust in all
> Internet services.
>
> To solve this problem we have tried to connect different identity silos
> together in various federated models. However these have produced
> inadvertent side effects such as concentrating control around a small
> number of providers, correlation of personal data through multiple
> seemingly unrelated transactions, increasing data leakage through
> inadvertent sharing, and raising privacy concerns, all while not actually
> giving the individual real control. At the same time, there is a growing
> economic inefficiency when organisations all around the world have to
> collect, store and protect the same sort of personal data in their own
> silos. It is reaching a tipping point.
>
> The next evolution of the Internet will be the creation of a common
> identity layer that allows people, organisations and things to have their
> own self-sovereign identity—a digital identity they own and control, and
> which cannot be taken away from them. Self-sovereign identity is the
> natural evolution of an ecosystem which has moved faster than its
> supporting capabilities.
>
> *Proposed benefits of the new solution space*
>
> To create the long-missing identity layer of the Internet, a new, trusted
> infrastructure is required which enables identity owners to share not only
> identity, but also verified attributes about people, organizations and
> things, with full permission and consent.
>
>
> For identities to be truly self-sovereign, this infrastructure needs to
> reside in an environment of diffuse trust, not belonging to or controlled
> by any single organisation or even a small group of organisations. Nobody
> can “turn the lights out”. Distributed ledger technology (DLT) is the
> breakthrough that makes this possible. It enables multiple institutions,
> organisations and governments to work together for the first time by
> forming a decentralised network much like the Internet itself, where data
> is replicated in multiple locations to be resistant to faults and tampering.
>
> When combined with distributed key management and peer-to-peer sharing of
> encrypted claims, DLT is what finally makes self-sovereign identity
> possible. Within this identity layer, mechanisms for discovery, routing of
> requests, secure exchange of information and management of consent, under
> the full control of the identity owner, finally becomes possible.
>
> The Sovrin Identity Network has been design specifically to deliver a
> globally scalable self-sovereign identity solution. But to be truly
> self-sovereign, it cannot be owned by anyone. Similarly, to be fully
> trusted, and to avoid the pitfalls of other initiatives in the distributed
> ledger space, Sovrin needs a lightweight governance layer. To achieve this,
> the developers of Sovrin have given away the source code to the Sovrin
> Foundation, a not-for-profit organisation whose role is to provide a thin
> layer of governance to Sovrin while not owning or managing any
> infrastructure. The Sovrin Foundation ensures the effective distribution of
> the decentralised network and ensures that the network itself functions in
> the best interest of its users.
>
> *Different approaches being taken in the new solution space, e.g. if other
> approaches are being taken outside of Sovrin*
>
> Early examples of identity solutions using distributed ledger technology
> used ledgers built for other purposes such as the Bitcoin ledger, or
> general purpose ledgers such as Ethereum. While these capabilities are able
> to provide fairly simple proofs that something took place on a certain date
> & time, they are not dedicated to the particular nuances of the identity
> ecosystem such as non-correlation, revocation and anonymous zero-knowledge
> proofs.
>
> They also lack governance. For example, the need to secure the network by
> using hashing power has resulted in a concentration of Bitcoin mining in
> China. Who are these miners, do we trust them, do they jointly exert too
> much influence. What governance is in place? The recent forking of Ethereum
> has also shown the consequences of a lack of governance and direction.
>
> Sovrin is the first public-permissioned distributed ledger. It is publicly
> accessible by anyone, but in order to run one of the nodes which validates
> the integrity of the network, you need to be permitted to and you must
> abide by certain rules which include the Sovrin Trust Framework.
>
>
> Non-distributed ledger solutions are attempting to paper over the problems
> with silo-based identity. Examples are federated identity models such as
> the gov.ukVerify system, which uses attribute sharing hubs and identity
> providers to move information from one silo to another, but without giving
> the identity owner real control. Personal information management solutions
> are going a step further, in enabling identity owner control of their data,
> but are still somewhat lacking in portability and therefore remain as silos.
>
>
> *Strengths, weaknesses, risks, and open issues being seen in practice*
>
> The ability for an identity owner to assert multiple verifiable claims
> about their identity, anonymously if required, and without possibility of
> correlation, is central to the architecture of Sovrin. With discovery
> capabilities to ensure that party A can confirm the identity of party B,
> and vice versa, direct party-to-party data sharing can take place with no
> need for intermediaries and with full evidence of consent.
>
> By replacing intermediaries with protocols, immediate digital identity
> verification can take place with no 3rd party involvement. There are too
> many benefits to list, bur here are a few that we are working on: instant
> employment screening; frictionless bank KYC, identity for the stateless,
> fast online checkout, globally portable digital identity for travellers,
> and vaccination recording for developing countries.
>
> Challenges to adoption of Sovrin are those typical of a two-sided market.
> Both identity issuers and relying parties need to come on board. Sovrin
> partners are taking a simple approach to this – the initial partners will
> be both issuers and relying parties. They will provide new identity
> services for their users to be utilised within their own ecosystem. These
> islands of functionality will expand and intersect with other islands, and
> individuals will find that they can use their identity information from one
> issuer with a completely different relying party. In other cases,
> coalitions of organisations which are all trying to solve the same problem
> are coming together to create an ecosystem where they can all use Sovrin to
> their mutual benefit.
>
> The other major challenge is an educational one. Trying to explain
> self-sovereign identity to a layman is difficult. Because people have been
> brought up to understand that the only way the internet works is to give
> their details to many different organisations repeatedly, they cannot
> conceive of a better way. Being able to get across the power of every
> individual having their own digital identity which they control and own and
> which cannot be taken away, is a new concept which needs to be communicated
> effectively.
>
> *Whether other technologies and techniques are being brought to bear (you
> can see a list of technologies and techniques we are analyzing in
> our report
> <http://kantarainitiative.org/confluence/display/BSC/Report+from+the+Blockchain+and+Smart+Contracts+Discussion+Group> TOC)*
>
> Sovrin enables/uses the following
> -          Public-permissioned distributed ledger technology based on the
> Plenum Consensus Protocol, involving multiple specialised legers (identity
> ledger, config ledger etc)
> -          Verifiable claims
> -          Anonymous credentials
> -          Revocation, anonymous if required
> -          Distributed and cryptographic identifiers
> -          Link contracts & consent receipting
> -          Persistent P2P messaging endpoints
> -          Key discovery, management recovery & rotation
> -          Portable off-ledger private data storage e.g. IPFS/BigChainDB
> etc.
> -          Identity, relationship and reputation graphs
> -          3rd party attested and self-attested claims
>
>
>
> On Oct 11, 2016, at 9:41 AM, Eve Maler <eve.maler at forgerock.com> wrote:
>
> Hi Phil-- Thanks for being willing to help the Blockchain and Smart
> Contracts group understand what Sovrin is doing in the context of our
> analysis efforts!
>
> If you look at the first paragraph of our draft report's introduction
> <http://kantarainitiative.org/confluence/display/BSC/Report+from+the+Blockchain+and+Smart+Contracts+Discussion+Group#ReportfromtheBlockchainandSmartContractsDiscussionGroup-Introduction>,
> you'll see a statement of our scope:
>
>    - Solving use cases for *empowering traditionally disempowered parties*
>    (such as individuals)
>    - taking part in *transactions* (such as entering into contracts and
>    information-sharing agreements)
>    - with *parties that traditionally hold greater power* (such as
>    companies and large countries)
>    - in the context of *decentralization technologies and techniques*
>    (such as blockchain and smart contracts)
>    - and their mixture with *identity* (both in the course of conducting
>    business/legal transactions and to solve digital identity use cases).
>
> Our Discussion Group is time-boxed to six months, and so we plan to go
> into only as much depth as can be covered in this time frame. (We started
> in July!)
>
> With all of this in mind, could you please comment on the following
> aspects of Sovin?
>
>    - Deficits and benefits of how the problem space was/is being solved
>    - Proposed benefits of the new solution space
>    - Different approaches being taken in the new solution space, e.g. if
>    other approaches are being taken outside of Sovrin
>    - Strengths, weaknesses, risks, and open issues being seen in practice
>    - Whether other technologies and techniques are being brought to bear
>    (you can see a list of technologies and techniques we are analyzing in our
>    report
>    <http://kantarainitiative.org/confluence/display/BSC/Report+from+the+Blockchain+and+Smart+Contracts+Discussion+Group>
>    TOC)
>
> Many thanks! If you have any questions, or would like to discuss responses
> in a phone call, don't hesitate to let me know.
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> *ForgeRock Summits* are coming to <http://summits.forgerock.com/> *London
> and Paris!*
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20161202/1bb7e95e/attachment-0001.html>


More information about the DG-BSC mailing list