European Workshop on Trust & Identity

In cooperation with GeantLogo184x80


  • Session 19 - Federated Registries

    Session 19 <Federated Registries > (14:15/Room K7)

    Convener: Richard O`Brien

    Abstract:End users, developers, and automated processes deal with persistently identified, self-explaining digital objects which are securely & redundantly managed & stored in the Internet which is an overlay on existing or future information storage systems.

    The Digital Object Cloud, as envisaged with Greenlist Federated Registries supplying discovery & verification of Digital Objects indexed in the Handle System and used in the DOI System as a component.

    Tags: Identifier, Digital Objects


    To orient this I am going to talk about a use case that we presented to the ITU about 18 months ago, and the one use case that we are focusing on is for the people that own accounts, private or company ones. We are looking at the problem of the unprivileged people that don’t have bank accounts but have prepaid cell phone accounts. If they were able to live in the electronic economy, we wouldn’t have the situation today where 70% of the people don’t have a bank account. This is one of those development areas of the economic Internet… We want to prevent wasting capital where there is too much imbalance of fee processing and other kinds of cash resources from one jurisdiction to another. This continues to exist today so the illustrative use case shows how it works, the payor identified to the account, he gives a name of a person to send money to, and the portal queries Greenlist, which obtains Virtual Identifier (VID) to match and Linked Credit Account (LCA) number, it can be an ACH, BIC/IBAN or debit card for example.

    A payor verifies if the payment is correct and the objective is to send an irrecoverable payment to a destination that has to be trusted. It’s a payee address that needs to be certified as accurate. It’s a proof that if you send money to that location that it’s going to go to the person that you want to send it to.

    The teachers can dispense rewards, we want to teach the children in the city that if you just do your homework to get some payments, it’s more efficient where the parents can actually learn from their children and there is no merchant fraud risk as the payments happen instantly, and there is a human capital growth involves local businesses and narrows the digital divide.

    The idea is to show that the teachers are allowed to a system of rewards and getting achievements. The point is to have digital objects to bind entities. We are terribly involved in smart contract work so we talk about digital objects, thinking in terms of registering, to have this container, to self-describe and the access control can be shown on a database level.

    Handle System is a distributed, open-sourced, deployed Digital Object Network Architecture and potentially can bind a pseudonymous name (via x.509 certificate) to every identifier of which bank provided an account for every student.

    The economics are sustainable - in the first year a lot of tablets were bought because of this system. And then the other part of this is the way we have mapping public identifiers and the 9 data points about account owners, and when to draw the money from the account is never given. Student enrols in the bank and the teachers enrol as the authorized payors to distribute funds and all of the regulations are conformed in the cloud, there is access control which is given by a bank to the cloud and we can have analytics who made most money etc. And if the student moves to a different state, that can still be used without having to reregister.

    DONA – Digital Object Network Architecture

    This is a same kind of standards process which brought the Internet into existence.

    In the US we have two very powerful service providers that do the back-office accounting for small and medium-sized banks and there are about ten banks that do the majority of credit-card processing in the US.

    In their world, if someone was to create new accounts that could just be synced using todays infrastructure. In different industries there could be the need for syncing for different types of services.

    The problem that we have to address is the need to have maintenance of trust even when there is not a perfect syncing. There is a way to see if the query is to a trusted registry, and there can be something in that registry that is out of sync and if you are using that query to move money and what we developed is to use multicast round robin is when one does a query to make a multicast sync to alert all registries where they would refresh.

    If something goes wrong, there will be a report back that some packets are missing. If there was an outage and no packets are sent, and the central doesn’t know if it’s in sync at all, so the timer in the overall system

    That directs the queries starts to tick and that maybe out of sync can occur for 24 hours, so you just have to determine the window that’s acceptable.

    By definition the window of recovery only has to be less than the recovery window(?). The big banks are trust worthy because of their reputation, oracle databases. And that’s the world today. Of the Internet and the fintec regulators and we will have systems that sync in those worlds. The new system is different and if you prove the trust with math it’s still better than just verifications. Money is only when it can be withdrawn with cash.

    The conclusion is that we should have a hybrid legacy (traditional database) and next generation (block chain, etc.) synchronization standard.