AU2017100968A4

AU2017100968A4 - System for issuance, verification and use of digital identities on a public or private ledger.

Info

Publication number: AU2017100968A4
Application number: AU2017100968A
Authority: AU
Inventors: Vojdan Kardalev; Emilija Poposka Kardaleva
Original assignee: Brontech Pty Ltd; Poposka Kardaleva Emilija Ms
Current assignee: Brontech Pty Ltd; Poposka Kardaleva Emilija Ms
Priority date: 2016-07-18
Filing date: 2017-07-16
Publication date: 2017-09-07
Anticipated expiration: 2025-07-16

Abstract

Abstract The present invention seeks to provide a system for creating, verifying and using sovereign digital identities that will incorporate different attributes (PIls- Personally identifiable information), which have an associated trust/risk score. This score represents a quantitative measurement of the trustworthiness and the veracity of those particular attributes. An overall trust/risk score of the digital identity can be calculated by combining the trust/risk scores of separate attribute associated with that particular identity. Furthermore, this invention provides a description of a decentralized infrastructure for managing such digital identities by utilizing cryptographic methods and distributed ledger (blockchain) technology. The presented system can be used for issuance, verification and use of digital identities for range of different subjects (person, organization, software agent, device, etc.).

Description

1 2017100968 16 Jul2017

Title of invention: System for issuance, verification and use of digital identities on a public or private ledger

Technical field [0001] The invention represents a system for issuance, verification and use of digital identities by leveraging cryptography and storing transaction proofs and data hashes on a public or private immutable ledger (blockchain). The system can be used directly via its web interface or indirectly via its APIs by various agents in the network (e.g. organizations, people, software programs, devices etc.) in a peer-to-peer manner. The core of the invention is composed of two modules: a module that enables the user to manage a sovereign identity on the network and a module that enables this agent that holds trustworthy digital identity to issue, receive, revoke or verify an identity node or attributes of other identity nodes.

Background [0002] Public/private ledger technologies or popularly called blockchain is a distributed database that holds immutable list of data records or code on a decentralized network of machines. The data or code are contained in data structures called blocks, where each structural block encompasses lots of separate transactions and the results of the executables (also called “smart contracts”). Additionally, each block contains timestamp and a reference to the previous block. Upon entry of each data or code in the ledger, it is almost impossible to alter or delete it. Each consequential data revision has to be recorded in the blockchain.

[0003] Currently there are several permissionless and permissioned blockchain implementations on the market (Bitcoin, Ethereum, Ripple etc.) that primarily facilitate peer-to-peer transaction of value (e.g. exchange of cryptocurrencies like Bitcoins or Ether). However, with the added ability the blockchain to store executable code in the blocks (e.g. such as in Ethereum) the potential uses for this technology widened. 2 2017100968 16 Μ 2017 [0004] As the world becomes more globalized and flat the interactions between various agents increase both in number and in frequency. Often, in order to engage in an interaction, the agents need to hold certain type of certificate that will prove their identity that can be related to their academic achievements (e.g. university diploma, course certificate), their degree of proficiency in a certain field (e.g. English test score), legal permission to conduct some profession (e.g. legal or medical license) or right to own something (e.g. gun license). As the agent interactions outgrows the geographical and jurisdictional boundaries, it is of vital importance to have a system in place that will represent a collection of these digital identities and/or attached pseudonyms to these identities, but at the same time be decentralized and manage data permissions with an integrated sovereign management system.

[0005] Currently, the issuance, management and revocation of identities is done via centralized enterprise databases. The proofs for existence of identities are managed by third party central databases that pose certain risks for data censorship, data tampering, single point of failure and denial of service attacks.

Summary of the Invention [0006] The present invention seeks to provide a solution to this problem by providing a system in which sovereign digital identities can be issued to any user of the system (person, organization, software agent, device, etc.), by any user of the system via its own sovereign digital identity or by use of the API.

[0007] A user can have one or more sovereign digital identities, which may be independent or dependent (pseudonym). The sovereign digital identity can have one or multiple owners. The sovereign digital identity comprises of a collection of data (called attributes) which can represent one or more pieces of information that the owner deems relevant towards representing his identity. The owner of the sovereign digital identity has full control over attributes, interactions and attestations stored as part of his sovereign digital identity such that he can choose to display them publicly, encrypt them, or just have a proof of their existence (by use of hashing, having an URI, token, etc.). Access and ownership of the sovereign digital identity and its comprising elements are controlled by the owner himself, but can also be delegated. 3 2017100968 16M2017 [0008] In a preferred embodiment, the veracity and trustworthiness of any sovereign digital identity can be assessed by generating a trust/risk score. Different trust/risk score algorithms (custom or predefined/preset) can be used for different purposes.

[0009] In a preferred embodiment, the generation of a trust/risk score, access to data attributes, or any other interaction is stored on the blockchain in such a way that the actions and results are auditable. Such auditable data may be created in such a way that it is publicly readable or so that it is only readable for specific parties (by the use of techniques such as hashing or encryption).

[0010] In a preferred embodiment, the access keys to the identity node may be passwords, cryptographic keys, biometric data, usage of multiple-factor authentication or similar methods. The access keys may be stored on a device (such as a smartphone, smart card, SD card, RFID card, NFC enabled card, EMV chip card or similar) or stored with a third party so the owner does not have to remember or enter the access credentials.

[0011] In a preferred embodiment, read access to the attributes cannot be attained except with the permission of the owner or if it is a special identity node type (e.g. an identity of a company with some attributes legally required to be publicly accessible).

Description of Preferred Embodiments [0012] The nucleus of identity data is contained within an "identity node". In a preferred embodiment, the identity node may contain but is not limited to the following: • GUID - Every identity node has its own Globally Unique identifier. The purpose of the GUID is to distinguish it from any other identity node. GUIDs can be automatically created (such as the blockchain address or a randomly generated unique number) or it can be an identifier assigned by a company, government, other entities or the user himself/herself. • Owners - the system will allow the identity to have one or more owners that will control the actions of the identity node. The owner can be but is not limited to a "wallet" or an identity node. 4 2017100968 16 Μ 2017 • Guardians - there can be one or more nominated controllers of the identity access keys that can reset the access keys if the owner loses control over the idintity account. The guardian can be but is not limited to a "wallet" or an identity node. • Identity attributes - cryptographically secure and provable identity attributes. Can be transferable, non-transferable, “needed to be reconfirmed” or of other type. Identity attributes can be dependent on certain conditions. • Relationship attributes (interactions) - Show a certain relationship between two or more identity nodes such as "is an employee of', "are shareholders in X with percentage Y", "is sibling of', etc. Can be transferable, non-transferable or needed to be reconfirmed. Interactions can be dependent on certain conditions. • Identity and relationship groups - A grouping of certain identity and relationship attributes needed for a specific purpose such as but not limited to: o e.g. Driving license

Age >18 years;

Driving test passed;

No driving bans, o e.g. Course instructor

Experience > 5 years;

Certification body approval;

Achieved score > 8;

Last certification renewal date < 1 year ago. • Access consent - Publicly accessible data access and data use consent of the identity node. This consent will approve or deny access and use of certain identity and relationship attributes by the stated parties or groups of parties. The consent can be, but is not limited to: o One-time access consent; o Multiple access consent; o Temporal consent (accessible from - to). and can be in reference, but not limited to: o Access to a specific attribute; o Access to a group or type of attributes; o Access for a specific purpose or under certain conditions. 5 2017100968 16 Μ 2017 and can be given for, but not limited to: o A specific person/identity node; o A group of identities (e.g. all employees of a certain company, all identities which owners reside in a specific country or identities with a reputation score above certain level); • e.g. Company A can access my data at from January 2016 to December 2016, Company B may not access my data unless in case of emergency, Company C may access my data for a certain fee.

[0013] The identity attribute content can be represented with but not limited to plain text (including alphanumerical values and special characters), media (video, images etc.), biometrics, encrypted or hashed values of certain data (such as date of birth, name, etc.), pointers towards data (such as URI, IPFS address, etc.). Any or all of the above stated identity node contents may be only proofs of data and not the data itself, such as storing a zero-knowledge proof of ownership of a valid driving license or age > 18, a zero-knowledge proof of having executed certain actions (such as payed 10% tax) or a signed certification of a certain attribute by a trusted third party (such as a bank certifying that an identity owns a certain bank account).

[0014] Identity attributes and relationship attributes can be but not limited to attributes that are transferable, non-transferable or “needed to be reconfirmed” . This means that if an attribute is flagged as transferable, the attribute stays "signed" even if the owner changes. For example of a transferable attribute would be an attribute of an identity of a company which changes shareholders or owners. Non-transferable attributes are "erased" (flagged as invalid) once the owner is changed. For example, a typical example of non-transferable attribute is an academic certificate (example Ph.D) which could not be transferred if the owner is changed. Attributes that need to be reconfirmed are attributes which would need to be checked for validity once the owner changes. If an identity or relationship attribute is flagged as dependent on certain conditions it means that the attribute will become invalid or will need to be reconfirmed if a certain condition changes (e.g. an employee with certain skills leaves the company). Such conditional principles are applicable to other identity segments.

[0015] Identity nodes may have certain functionalities they can execute or can be executed on them. These functionalities include, but are not limited to: • CRUD identity nodes and attributes (Create, Read, Update, Delete); 6 2017100968 16 Μ 2017 • Add/edit owners; • Add/edit guardians; • Log-in with password; • Log-in with biometrics; • Log-in with multi-factor authentication; • Flag attribute or transaction as erroneous. Certain attributes or transaction can be of types which cannot be "deleted" (forgotten). In some cases, a third party will have to check the veracity; • Generate hierarchically deterministic (HD) identity nodes or access keys from current identity node; • Add a transaction as an attribute (add a blockchain transaction as an identity/relationship attribute); • Edit transaction quorum (e.g. must have 2 out of 3 owner signatures or 3 out of 5 guardians must agree to regenerate access keys); • Join identities i.e. to combine multiple identities in single entity; • Attest identity or attributes; • Request attestation of identity or attributes; • Prove the owners identity. Prove that someone is the owner of an identity or of certain identity’s attributes; • Request an identity verification i.e. be able to invite other identity owners or third parties to check the veracity of the identity attributes and act as attesters; • Search for a particular identity node or attributes. The user can search for identities satisfying certain conditions. In order the identities to be searchable, owners must give explicit consent for these nodes to be indexed (searchable); • Update/edit access consent; • Get access consent; • Generate reputation/risk score for a specific application such as opening a bank account, creating a social network profile etc. Reputation/risk score can be dependent on attributes, transaction and how recent they are; • Compute identity trust score via algorithm that receives inputs such as but not limited to: peer and third party attestations, uploaded documents by the identity owner, history of transactions, social media logins etc.; • Regenerate encryption or ownership keys either by the owner or by the nominated guardians; 2017100968 16 Μ 2017 7 • Share (access/encryption) keys; • Revoke (access/encryption) keys; • Generate identity graph (return data needed to visualize the identity's attributes and connections); • Edit encryption protocols (asymmetric cryptography, symmetric cryptography, cryptographic signature types and algorithms, attribute-based encryption, etc.).

Storage of the data can be done in a few ways according to the user or use-case requirements. The data storage can be, but is not limited to: • Fully stored on the blockchain as plain text (unencrypted); • fully stored on the blockchain as ciphertext (encrypted); • fully stored with mixed plain text and ciphertext; • all data is stored off-chain (in a database), but the hashes (or a similar technique of verifying integrity) or tokens (a reference to where the data is stored) are stored on the blockchain; • mixed storage - some parts of the data are stored on the blockchain and some are stored off-chain.

[0016] If the data (some or all) is stored off-chain, the user can choose between private storage (he/she can store the data on a computer, smart device, memory card, RFID card, etc.), company/government storage (Storage-as-a-service) or be stored in another way that the specific use-case allows.

[0017] Encryption/hashing and resistance to hacking can be accomplished by using random phrases or numbers as cryptographic seeds. These seeds can be stored in a hardware device or a smartphone to increase usability.

[0018] Logging in (obtaining access) to the identity node can be done with a use of password, digital token (hardware device or on a smart device such as a smartphone) or by using biometrics. 8 2017100968 16 Μ 2017

Brief Description of the Drawings [0019] The present invention will now be more particularly described, with reference to the accompanying drawings, by way of example only and in no way limiting the scope of the invention, in which: [0020] Figure 1. describes the comprising elements that belong to an identity node (pseudonym); [0021] Figure 2. describes the way identity nodes (pseudonyms) are connected in the system and different types of connections between them; [0022] Figure 3. describes an example calculation algorithm of the identity trust/risk score. Detailed description of the drawings [0023] Figure 1. describes the elements that belong to an identity node (pseudonym) 1000. It's element may include, but are not limited to data attributes 1100, interaction (such as transaction, communication, etc.) 1200, access consent 1300, encryption keys 1400, list of owners 1500, list of guardians 1600 or other data deemed relevant 1700 by the owner to be part of the identity node.

[0024] Figure 2. describes the way identity nodes (pseudonyms) 2000 are connected in the system and the types of connection (such as ownership, attestation, etc.). An identity node may own other identity nodes. There may be more than one owner of a single identity node. Guardians are chosen by the identity owners and may help in restoration of access to the identity node in case of loss of password or access keys. Identity nodes may attest its own or other's data attributes 2100 as proof of their veracity. An identity may also own interactions 2200, which represent actions taken by an identity. Interactions can be single-sided (there is no other party or identity node in the interaction) or they can be multi-sided (there are one or more other identity nodes taking part in the interaction). An identity node may also own one or more encryption keys (such as symmetric keys, asymmetric keys, PGP keys, etc.) 2300. 2017100968 16 Μ 2017 9 [0025] Figure 3. describes the calculation if the identity trust/risk score 3600. Any identity node 3000 may use its own custom algorithms 3100, or it may decide to use predefined algorithms 3200 in order to calculate the trust/risk score of another identity node 3700. Whichever algorithm is chosen, it may contain different levels 3300 of trust. Any trust level 3300 may contain one or more entities 3400. An entity 3400 may be but is not limited to an identity node, a group of identity nodes, an interaction or any other entity which may prove useful in evaluating the trust score of the targeted identity 3700. The calculation of the specific score 3500 an attestation adds to an identity 3700 is done by multiplying the level score 3350 (which may be different for every level, or may even be negative) with a factor 3700 which may be dynamic (e.g. dependent on the identity score of the node giving the attestation, dependent on certain connections between the entities 3450, etc.) or it may be fixed. The complete identity score 3600 of an identity node 3700 is calculated by a sum of all specific scores 3500 that derive from calculations implemented in the algorithms 3100; 3200.

Claims

Claims

1. Method for creating digital identity with a nucleus of identity data contained within an identity node. a. Create a Globally Unique identifier (i.e. a distributed ledger (blockchain) address); b. Assign identity owners and guardians; c. Create cryptographically secure and provable identity attributes and relationships between the attributes; d. Create consent mechanism for access to particular attributes.
2. Method for accessing the veracity of particular identity or its attributes by calculating a trust/risk score. a. Trust/risk score is a quantitative measurement of the trustworthiness of a particular identity or its attributes by incorporating independent assessments by verified attesters of particular attribute (e.g. a banks verifying subject’s age). b. Trust/risk score of an identity is the aggregate of the trust/risk scores of its constituents (attributes).
3. The identity attribute content can be represented as plain text, media, encrypted or hashed values of certain data or pointers towards data.
4. Attachment of flags to identity attributes as transferable, non-transferable or needed to be reconfirmed.
5. Identity attributes can be stored fully on chain (on a distributed ledger-blockchain) or off chain with cryptographic proofs (hashes) stored on the distributed ledger (blockchain).