[go: up one dir, main page]

WO2024116104A1 - Système d'identités décentralisées déléguées - Google Patents

Système d'identités décentralisées déléguées Download PDF

Info

Publication number
WO2024116104A1
WO2024116104A1 PCT/IB2023/062049 IB2023062049W WO2024116104A1 WO 2024116104 A1 WO2024116104 A1 WO 2024116104A1 IB 2023062049 W IB2023062049 W IB 2023062049W WO 2024116104 A1 WO2024116104 A1 WO 2024116104A1
Authority
WO
WIPO (PCT)
Prior art keywords
party
identity
user
private key
credentials
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/IB2023/062049
Other languages
English (en)
Inventor
Ric B Richardson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Pci Global Inc
Original Assignee
Pci Global Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2022903641A external-priority patent/AU2022903641A0/en
Application filed by Pci Global Inc filed Critical Pci Global Inc
Publication of WO2024116104A1 publication Critical patent/WO2024116104A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/006—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0847—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving identity based encryption [IBE] schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response

Definitions

  • the present application relates to a system of delegate decentralised identities or more generally, a delegation system. More particularly although not exclusively, it relates to an online delegation system which facilitates delegation of identities or credentials or communications. In preferred forms it does this by way of a delegate device operable by a delegate.
  • Valid situations where this can occur include power of attorney or delegate actions where a second party is authorised legally to act on the behalf of a first pally by the first party. Or where an elderly parent requests a child to act on their behalf due to old age or lack of technical ability. Or where a parent establishes a decentralised identity or public key digital identity for their minor/ child that they take control over later in life.
  • delegate identities An alternative to using delegate identities is for third parties to supply a delegate registration service that allows users to approach an online service or counterpart and request that they recognise their delegate as a legal representative for them on their behalf.
  • US Application 2918/0041484 to Gifford - assigned to Kryptco Inc - relates to a system for delegated cryptography.
  • the nature of the delegation is different to the delegation envisaged in the present application. Further differences as between Gifford and features of the present application include:
  • Gifford discloses a device delegation system that is ideal for allowing a user to keep their public keys on a mobile device and then allow other devices the user use and controls to act as “delegated” devices on behalf of the phone to allow a convenient device such as a laptop to use online services supplied by a second party by the first party.
  • a first party is delegating authority to a second party to act as a delegate of the first party to contact and interact with a third party.
  • the second party is NOT the first party using a secondary device.
  • connection between the second device and the second party is an SSH session which acts as a secure pipe within which a session between the delegate device and the first device can relay requests for authentication as if the first device was actually connected to the third device.
  • Richardson is different because the connection between the first party and its device and the second party and its device is authenticated with its own public key pair exchange before requesting that the first party device authenticate an authentication request from a third party and its device.
  • a delegate is a separate autonomous person with a separate device to that controlled by the first party who has been given delegation powers by the first party to use public keys on the first party device to connect to third party devices on behalf of the first pally and where the connection between the second party and the third party is done at the will of the second party and the second pally device using the identity and authentication capability allowed to it by the device of the first party using a rules database on the first party device.
  • a system implemented as an asymmetric or public key based identity, credentials and or communication system that allows a user in the form of a first party to facilitate delegation of those identities, credentials and communications; the system: a. opening a separate secure communication and identity verification communication and identity channel between a first party and a second party; b. the system then allowing the second party to access identity and credentials on the device controlled by the first party to be used by the second party on behalf of the first party; c. the second party then connecting with a third party for the purposes of identity verification, authentication and secure communication on behalf of the first party.
  • the second party initiates a connection with the third party using the public key of the first party as a form of identity and then; verify the identity of the first party with the third party at the initiation of the second party by; making a remote connection from the second party to the first party in order to have an identity challenge signed or authenticated by the first parties device by using the first party's private key without copying that private key to the second party's device.
  • the system is effected without sharing or allowing a copy of the private key components of the public key pairs involved to be directly accessed by the second party who is the delegate; and without allowing a private key of the first pally to be copied to the delegates device for local use by the delegated party; whereby the access to the private key is only allowed remotely while it continues to be in the control of and in the possession of the user.
  • connection between the device of the first party and the device of the second party is protected.
  • connection between the device of the first party and the device of the second party is protected by standard security measures known in the art.
  • the remote access to the private key or keys of the first party involved is based on a set of rules and conditions that the first party has agreed to and is in control.
  • the set of rules and conditions may include but not be limited to restrictions on the identity of who can access the first parties identity or credential, a window of time in which access is granted as well as use case restrictions such as limiting the keys use to specific web domains, web sites or applications.
  • the remote, rule-based access to the user's private key components allows a delegated second party to securely interact with a third party on the behalf of the first party and perform a full range of identity, credentials and secure communications capabilities and activities without directly accessing the private key components of the first party.
  • Preferably use of the private key is achieved without allowing a private key to be copied to the delegate's device for local use by the delegated party.
  • the access to the private key is only allowed remotely while it continues to be in the control of and in the possession of the user;
  • the user of the device upon which the private keys are stored may or may not be aware that the delegate is using those private keys on the user’s behalf.
  • the device storing the private key components is available for remote access.
  • a method of operation of a delegation system comprising at least a first party, a second party and a third party and controlled and authenticated communication between at least a first party, a second party and a third party; said method implemented as an asymmetric or public key based identity, credentials and or communication system; steps of said method including: a. allowing a user in the form of the first party to facilitate delegation of those identities, credentials and communications; b. opening a separate secure communication and identity verification communication and identity channel between the first party and the second party; and then; c.
  • the second party attempts to connect with the third party using the public key of the first party as a form of identity and then verifying the identity of the first party with the third party at the initiation of the second party by making a remote connection from the second device of the second party to the first device of the first party in order to have an identity challenge signed or authenticated by the first device of the first party by using the private key of the first party without copying that private key to the second device of the second party.
  • the method is effected without sharing or allowing a copy of the private key of the public key pairs involved to be directly accessed by the delegate; or allowing a private key to be copied to the delegates device for local use by the delegated party; whereby the access to the private key is only allowed remotely while it continues to be in the control of and in the possession of the user.
  • a remote access to the private key or keys involved is based on a set of rules and conditions that the user of the first device has agreed to and is in control of.
  • the user of the device upon which the private keys are stored may be aware that the delegate is using those private keys on the user’s behalf.
  • the user of the device upon which the private keys are stored may not be aware that the delegate is using those private keys on the user’s behalf.
  • the device storing the private key components is available for remote access.
  • the remote, rule-based access to the user's private key components allows a delegated second party to securely interact with a third party on the behalf of the first party and perform a full range of identity, credentials and secure communications capabilities and activities without directly accessing the first party user's private key components.
  • a system implemented as an asymmetric or public key based identity, credentials and or communication system that; a. allows a user to facilitate delegation of those identities, credentials and communications; b. The system opening a separate secure communication and identity verification communication and identity channel between a first party and a second party and then; i. allowing the second party to access identity and credentials on the device controlled by the first party to be used by the second party on behalf of the first party ii. Connecting with a third party for the purposes of identity verification, authentication and secure communication.
  • a second party attempts to connect with a third party using the public key of the first party as a form of identity and then; i. verify the identity of the first party with the third party at the initiation of the second party by;
  • the system is effected: a. sharing or allowing a copy of the private key components of the public key pairs involved to be directly accessed by the delegate; b. allowing a private key to be copied to the delegates device for local use by the delegated party; c. Whereby the access to the private key is only allowed remotely while it continues to be in the control of and in the possession of the user.
  • the remote access to the private key or keys involved is based on a set of rules and conditions that the user has agreed to and is in control of.
  • the user of the device upon which the private keys are stored may be aware that the delegate is using those private keys on the user’s behalf b. the user of the device upon which the private keys are stored, may not be aware that the delegate is using those private keys on the user’s behalf c. But where the device storing the private key components is available for remote access d. And whereby the remote, rule-based access to the user's private key components allows a delegated second party to securely interact with a third party on the behalf of the first party and perform a full range of identity, credentials and secure communications capabilities and activities without directly accessing the first party user's private key components.
  • an asymmetric or public key based identity, credentials and or communication system that; a. allows a user to facilitate delegation of those identities, credentials and communications; b. It does this by opening a separate secure communication and identity verification communication and identity channel between a first party and a second party and then; i. allowing the second party to access identity and credentials on the device controlled by the first party to be used by the second party on behalf of the first party ii. Connect with a third party for the purposes of identity verification, authentication and secure communication. c. In practise this would mean that; i. a second party would attempt to connect with a third party using the public key of the first party as a form of identity and then; ii. verify the identity of the first party with the third party at the initiation of the second party by;
  • the user of the device upon which the private keys are stored may or may not be aware that the delegate is using those private keys on the user’s behalf h. But where the device storing the private key components is available for remote access i. And whereby the remote, rule-based access to the user's private key components allows a delegated second party to securely interact with a third party on the behalf of the first party and perform a full range of identity, credentials and secure communications capabilities and activities without directly accessing the first party user's private key components.
  • a method of operation of a delegation system said method implemented as an asymmetric or public key based identity, credentials and or communication system; said method a. allowing a user to facilitate delegation of those identities, credentials and communications; b. opening a separate secure communication and identity verification communication and identity channel between a first party and a second party and then; i. allowing the second party to access identity and credentials on the device controlled by the first party to be used by the second party on behalf of the first party ii. Connecting with a third party for the purposes of identity verification, authentication and secure communication.
  • a second party attempts to connect with a third party using the public key of the first party as a form of identity and then; i. verify the identity of the first party with the third party at the initiation of the second party by;
  • the remote access to the private key or keys involved is based on a set of rules and conditions that the user has agreed to and is in control of.
  • the user of the device upon which the private keys are stored may be aware that the delegate is using those private keys on the user’s behalf b. the user of the device upon which the private keys are stored, may not be aware that the delegate is using those private keys on the user’s behalf c. But where the device storing the private key components is available for remote access d. And whereby the remote, rule-based access to the user's private key components allows a delegated second party to securely interact with a third party on the behalf of the first party and perform a full range of identity, credentials and secure communications capabilities and activities without directly accessing the first party user's private key components.
  • a second device of the second party connects with a third device of the third party for the purposes of identity verification, authentication and secure communication by the second party acting as a delegate of the first party.
  • Fig 1 is a block diagram of main components of a first example embodiment.
  • Fig 2a is a block diagram of a prior art example of identity authentication between user and 3rd pally service.
  • Fig 2b is a block diagram of an implementation of the delegated authentication based on the example embodiment of Fig 1.
  • Fig 3 is a flowchart of the process to establish delegated access to identity and credentials in accordance with an embodiment of the invention.
  • Fig 4 is a flowchart of an example of the process to establish delegated account access using the example embodiment of Fig 1.
  • a first party is delegating authority to a second paily to act as a delegate of the first party to contact and interact with a third party.
  • a second device of the second party connects with a third device of the third party for the purposes of identity verification, authentication and secure communication by the second party acting as a delegate of the first party.
  • the example embodiment discloses a delegate identity system which allows a second party to act on the behalf of a first party in an exchange with a third party.
  • the third pally is a server that requires identity authentication before allowing access to a provided service and account on the server.
  • Figure 1 discloses the main components of an example embodiment of the delegate identity system.
  • the first paily 10 uses a device 11 that contains an identity wallet 12 that in turn contains identities 13 that comprise key pairs of public and private keys 14 15 for use with individual accounts and secure activities provided by third party servers 16 and accessible over public and private networks 17.
  • the first parties device 11 may also store private data 18 and credentials 19 which are capable of being used in conjunction with the first parties digital identities 13.
  • a first party 10 would access the service or activity on a third party service 16 by connecting to it over the internet 17. Firstly, the user would use public key interactions that are known in the art to both verify the identity of the service and to validate their own identity and request access to the account 20 that the third party runs on their server 16 that is linked to the identity 13 provided by the first party 10.
  • the third-party server 16 contains a user database 22 that includes separate user accounts 20 that allow the user 10 to access services and data provided by the service 16.
  • a user database 22 that includes separate user accounts 20 that allow the user 10 to access services and data provided by the service 16.
  • users are identified by a unique username and or by the public key 21 of the user’s public key pair 14 15.
  • a credential 19 supplied by the user is verified against the user's verified identity 13 and then those credentials 19 are used by the servers 16 credential rules system 23 to ensure the user 10 gets access to the appropriate services and data on the service.
  • the second party 24 has a delegate identity 27 which is a public key pair used by the second party to securely identify themselves to the first party 10, verify the connection and then obtain access to the first party's public key identity system 13 in order to act on the behalf of that party.
  • delegate identity 27 is a public key pair used by the second party to securely identify themselves to the first party 10, verify the connection and then obtain access to the first party's public key identity system 13 in order to act on the behalf of that party.
  • Access to the identities 13 and related credentials 19 or data 18 is governed by a rules engine 30 on the device 11 of the first party.
  • This rules engine 30 controls incoming requests for access and communication from the second party 24 to ensure that the rules governing the delegate's authority are maintained.
  • the rules database 30 could dictate that the delegate party 24 only be given access to the digital identity 13 for access to a specific internet domain.
  • an adult child may be able to use their parent’s identity to manage their electricity bills and services, but not to allow access to their law firm's copy of their last will and testament even if the parents use the same public key digital identity.
  • the first party 10 will set the rules for which and under which the second party 24 will access their public key identity 13. Any request coming from the second party 24 to the first party 10 for access to identities 13, credentials 19 or data 18 will be governed by the rules of the rules database 30.
  • the first party 10 shares only the public key 14 of the public key pair 13 for each identity the second party 24 has been granted access to.
  • the shared public key 14 is stored 32 on the delegate's device 25 in a delegate identity storage record 31 and is only accessed by the delegate in accordance with the rules 33 that the delegate has agreed to as part of a delegation agreement.
  • the second party 24 When the second party 24 wishes to act on the behalf of the first party 10, the second party 24 who is also the delegate checks to see that the first party’s device 11 is online and available and a connection to the user's wallet 12 and related identities 13 and credentials 19 are also available. Then the second party 24 connects to the third party 16 on behalf of the first party 10 and supplies identity 13, data 18 and credentials 19 as needed to complete the authentication of the user by the third party 16.
  • Figure 2a shows an example known in the art of how a first party typically authenticates or verifies identity with a third party using technology typically identified with web three decentralised identity.
  • a user 40 with a device 41 typically contains a wallet 50 that in turn contains identities 42 and credentials 45.
  • Identities 42 typically comprise a public key pair which means that each pair has a public key 43 and a private key 44.
  • the public key 43 is used for uniquely identifying the owner or user 40 and the private key 44 is not shared but used for decrypting data that is sent to the user 40 using the public key 43.
  • the third party service 46 wishes to verify the user 40 wishing to connect to and use an account 47 on their service 46 one technique that is used is for the server to check a listing of existing accounts 47 on the server. These accounts 47 may be linked to public keys 48 or hashes of public keys that uniquely identify the account user 40. In a typical public key exchange the server 46 may ask the user 40 to verify their identity by asking the user to sign a message using their private key 44 so that they, the third party service 46, can use the public key 43 48 of the user's key pair to verify the user's possession of the private key 44.
  • the third party 46 can request a digitally signed credential 45 from the user for use by the third party service 46 to specify what capabilities, services and data the user can use during their session visiting the third party service 46 based on the credential usage rules 49 that are determined by the third party service 46.
  • the example embodiment of the invention uses the same basic process as that shown in figure 2a, however the person 60 initiating and managing the connection between the user 61 and the third party service 62 is a second pally in the role of delegate.
  • This person 60 first uses their device 63 to check and confirm that the device 64 of the first party is online and available, then establishes its own secure connection 65 between itself 63 and the device of the first party 64 using public key identity verification as known in the art.
  • This process involves the use of a digital identity 72, a public key 73 and signed confirmation or authentication provided by the use of the delegate's private key 74.
  • the delegate 63 After establishing its identity 72 with the delegators device 64 the delegate 63 initiates a connection with the third pally 62 on behalf of the first party 61 . It does this by identifying itself 63 with the identity 75 of the party it is delegating for. Typically this involves supplying a copy of the stored public key 76 of the first party 64 to the third party service 70 so that it can match the identity to the account 70 and specifically the related public key 78. In practise this may be a hash of the user's public key 68 76.
  • the server 62 then asks the delegate second pally 63 for a unique identifier 66 and credentials 67 for its service 62. Typically, it will also ask for digitally signed proof that the first paily is in possession of the identity private key 68.
  • the delegate 63 in turn processes the request from the third paily service 62 by requesting access to the relevant identity 66 and credentials 67 from the wallet 79 of the first user. In so doing, the first party's wallet 79 checks the user's access rules database 69 and verifies that the delegate 63 has the appropriate authority to obtain the identity 66 and credentials 67 and then allows the private key of the first paily 68 to be used to sign a proof of identity at the request of the third party 62.
  • the third party service 62 verifies the digital signature of the first paily 64 and account access 70 is granted based on the access rules allowed 71 by the user's credentials 67 even though the party that is initiating and running the active session with the third party 62 is the delegate 60 and not the first party 61.
  • This delivers a valuable capability which allows delegates or second parties 60 to use and administer accounts 70 on third party services 62 while guaranteeing that the first parties 61 unshared identity elements, namely their private key 68, is never copied or shared with anyone and is only remotely used based on rules 69 under which the user 61 has previously agreed.
  • This important privacy and security functionality also allows the first party 61 to withdraw delegate powers from second party 60 or modify the rules 69 under which a delegate can operate on the behalf of a first party 61.
  • Figure 3 discloses an example of the process used to establish delegated access to identity and credentials.
  • Figure 3 discloses how a second party interacts with a third party on the behalf of the first party in order to conduct trusted communications and activities on the behalf of the first party.
  • the process shows interaction between a delegator 80 of identities and credentials and a delegate 81 who wishes to act on behalf of the delegator.
  • the delegate applies 82 to the delegator for the authority to act as a delegate using predetermined and pre-agreed rules of usage which the delegate agrees to abide by.
  • the delegator recognises or ignores 83 the request of the delegate and subsequently allows or disallows a connection and relationship between them. This process typically uses a form of public key secure communication and or digital credentials both of which are known in the art.
  • the delegate When the delegate wishes to act on behalf of the delegator, the delegate makes a request for access to the delegators account 84. The delegator grants access to the account identity and credentials and sets rules for the use of the identity and credentials 85. Then a rules usage database defining the access rights of the delegate is updated or produced 87.
  • Examples of the rules 87 that could govern the use of the private keys of the first party by the second party could include but not be limited to requiring that the second party is verified and authorised for a connection and use of the first parties key pair and possibly further that the request for use of the first parties identity key pair be in relation to a specific verified third party online service by the second party on the behalf of the first party as specified by the rules database.
  • rules criteria could include but not be limited to restrictions and dates for which the private keys of the first party could be used; the number of times the private keys of the first party can be used, for example in a one time use situation or a limited number of transactions type of situations, or in more complex situations where the rules database requests more comprehensive transaction information such as the nature of the transaction, whether funds are involved and the maximum amount of the transaction before authorising the use of the private key for the transaction.
  • the rules database sets bounds for the access of a second party to the identity keys of the third party in the event their personal supervision of the transaction is not required.
  • the delegate is informed of the access rules and terms that have been allowed by the delegator and they are asked for their agreement 88. If the delegate agrees 90 then the delegator authorises 89 the delegate for future actions using the delegators identities and credentials as per the rules outlined in the rules database. Subsequently the delegator is notified of the delegate allowance 92 and the process terminated 94.
  • Figure 4 discloses an example of a process to establish delegated account access using the example embodiment.
  • This process includes three main parties.
  • the first party 100 is typically a delegator
  • the second party 101 is typically a delegate
  • the third party 102 is typically a service or online resource that the first party 100 wishes to use.
  • the delegate 101 wishes to access the third party service 102 on behalf of the first party 100.
  • the delegate wants to initiate 103 a transaction on behalf of the delegator.
  • the delegators device checks to see if the delegators device is online 104. If not, 105 then the process ends 106.
  • This step is known in the art.
  • the first party authorises the delegate 109 for a transaction according the rules in the rules database.
  • the device for the first party supplies the credentials needed for the transaction 110 to the delegate who in turn receives them 111 and the delegate requests 112 access to the third party service using the first party's identity and credentials.
  • the identity verification request is relayed 115 to the delegators device and the identity proof is provided 116.
  • this is something like a signed confirmation of some sort that proves the first party is in possession of the identity's private key. This step is known in the art.
  • the confirmation is relayed 117 back to the third party which in turn verifies the identity of the first party 118 at which point the account access is granted 119 at which point the delegate begins to use the account 120 on behalf of the delegator and any changes to the account recorded back to the delegators device 121 to maintain and update its settings if required and the process is ended 122.
  • the system may be implemented as an asymmetric or public key based identity, credentials and or communication system that; a. allows a user to facilitate delegation of those identities, credentials and communications; b. It does this by opening a separate secure communication and identity verification communication and identity channel between a first party and a second party and then; i. allowing the second party to access identity and credentials on the device controlled by the first party to be used by the second party on behalf of the first party ii. Connect with a third party for the purposes of identity verification, authentication and secure communication.
  • the system may operate as follows: a. a second party would attempt to connect with a third party using the public key of the first paily as a form of identity and then; i. verify the identity of the first party with the third party at the initiation of the second party by;
  • the remote access to the private key or keys involved is based on a set of rules and conditions that the user has agreed to and is in control of.
  • the user of the device upon which the private keys are stored may be aware that the delegate is using those private keys on the user’s behalf b. the user of the device upon which the private keys are stored, may not be aware that the delegate is using those private keys on the user’s behalf c. But where the device storing the private key components is available for remote access d. And whereby the remote, rule-based access to the user's private key components allows a delegated second party to securely interact with a third pally on the behalf of the first party and perform a full range of identity, credentials and secure communications capabilities and activities without directly accessing the first party user's private key components.
  • the example embodiment discusses one delegator interacting with one delegate. a.
  • An alternative embodiment could see many delegators delegating to a single delegate for multiple delegates serving as delegates for a single delegator or any combination of the same.
  • the example embodiment uses a public key pair for identity.
  • Alternative embodiment could use any flavour of asymmetric public key cryptography including but not limited to Shamir's algorithm or utilising public key protocols.
  • the example embodiment uses a rules database to define how the second party interacts with identities, credentials and data on the first party device. a. Alternative embodiments could see the rules encapsulated in a credential or series of digital credentials to achieve the same result.
  • the example embodiment shows a transaction where identity verification is required.
  • a In the event that a 3rd party does not require proof of authentication and or real time access to a private key then the delegator can allow rules based access to credentials and data for offline use for a limited time period.
  • b Recommended that any private data modification done by delegate be synchronised back to the delegator when they are again online and preferentially no local storage by delegate of that data after the synchronisation has occurred.
  • Embodiments of the invention may be utilised to permit an independent entity to operate on behalf of another entity.
  • operation is implemented by use of digital communications devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

Un système mis en œuvre sous la forme d'un système de communications, de justificatif d'identité ou d'identité basée sur des clés publiques ou asymétrique permet à un utilisateur sous la forme d'une première partie de faciliter la délégation de ces identités, de justificatifs d'identité et de communications ; le système permet : (d) l'ouverture d'une communication sécurisée séparée et d'une communication de vérification d'identité ainsi que d'un canal d'identité entre une première partie et une seconde partie ; (e) le système permet ensuite à la seconde partie d'accéder à l'identité et aux justificatifs d'identité sur le dispositif contrôlé par la première partie pour pouvoir être utilisé par la seconde partie au nom de la première partie ; la seconde partie se connecte ensuite à une tierce partie à des fins de vérification d'identité, d'authentification et de communication sécurisée au nom de la première partie. Un procédé de fonctionnement d'un système de délégation est également divulgué : le système comprenant au moins une première partie, une seconde partie et une tierce partie et une communication contrôlée et authentifiée entre au moins une première partie, une seconde partie et une tierce partie. Les étapes dudit procédé incluent : a) la facilitation de la délégation d'identités, de justificatifs d'identité et de communications par un utilisateur sous la forme de la première partie ; b) l'ouverture d'une communication sécurisée séparée et une communication de vérification d'identité et un canal d'identité entre la première partie et la seconde partie ; et c) l'accès par la seconde partie à l'identité et aux justificatifs d'identité de la première partie sur un premier dispositif contrôlé par la première partie ; d) la connexion par la seconde partie à un dispositif de la tierce partie à des fins de vérification d'identité, d'authentification et de communication sécurisée au nom de la première partie.
PCT/IB2023/062049 2022-11-30 2023-11-30 Système d'identités décentralisées déléguées Ceased WO2024116104A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2022903641A AU2022903641A0 (en) 2022-11-30 System of delegate decentralised identities
AU2022903641 2022-11-30

Publications (1)

Publication Number Publication Date
WO2024116104A1 true WO2024116104A1 (fr) 2024-06-06

Family

ID=91323089

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2023/062049 Ceased WO2024116104A1 (fr) 2022-11-30 2023-11-30 Système d'identités décentralisées déléguées

Country Status (1)

Country Link
WO (1) WO2024116104A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110302425A1 (en) * 2010-06-03 2011-12-08 Ramakrishna Saripalli Systems, methods, and apparatus to virtualize tpm accesses
US20140026200A1 (en) * 2011-04-15 2014-01-23 Nokia Corporation Method and apparatus for providing secret delegation
US20180041484A1 (en) * 2016-08-03 2018-02-08 KryptCo, Inc. Systems and methods for delegated cryptography
WO2019091907A1 (fr) * 2017-11-10 2019-05-16 Eth Zurich Délégation négociée de justificatifs d'identité utilisant des environnements d'exécution de confiance
US20200280855A1 (en) * 2018-08-21 2020-09-03 HYPR Corp. Secure mobile initiated authentication
US11502827B1 (en) * 2021-09-03 2022-11-15 Garantir LLC Exporting remote cryptographic keys

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110302425A1 (en) * 2010-06-03 2011-12-08 Ramakrishna Saripalli Systems, methods, and apparatus to virtualize tpm accesses
US20140026200A1 (en) * 2011-04-15 2014-01-23 Nokia Corporation Method and apparatus for providing secret delegation
US20180041484A1 (en) * 2016-08-03 2018-02-08 KryptCo, Inc. Systems and methods for delegated cryptography
WO2019091907A1 (fr) * 2017-11-10 2019-05-16 Eth Zurich Délégation négociée de justificatifs d'identité utilisant des environnements d'exécution de confiance
US20200280855A1 (en) * 2018-08-21 2020-09-03 HYPR Corp. Secure mobile initiated authentication
US11502827B1 (en) * 2021-09-03 2022-11-15 Garantir LLC Exporting remote cryptographic keys

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HERBOM STEPHEN, HUBER ANDREAS, BORELI ROKSANA, SENEVIRATNE ARUNA: "Secure Host Identity Delegation for Mobility", 1 January 2007 (2007-01-01), XP093179171, Retrieved from the Internet <URL:https://ieeexplore.ieee.org/stampPDF/getPDF.jsp?tp=&arnumber=4268020&ref=aHR0cHM6Ly9pZWVleHBsb3JlLmllZWUub3JnL2RvY3VtZW50LzQyNjgwMjA=> *
SHEHU ABUBAKAR-SADIQ, PINTO ANTÓNIO, CORREIA MANUEL: "Providing Secured Access Delegation in Identity Management Systems : ", PROCEEDINGS OF THE 17TH INTERNATIONAL JOINT CONFERENCE ON E-BUSINESS AND TELECOMMUNICATIONS, SCITEPRESS - SCIENCE AND TECHNOLOGY PUBLICATIONS, 1 January 2020 (2020-01-01) - 10 July 2020 (2020-07-10), pages 638 - 644, XP093179169, DOI: 10.5220/0009892206380644 *

Similar Documents

Publication Publication Date Title
JP3505058B2 (ja) ネットワークシステムのセキュリティ管理方法
CN101222488B (zh) 控制客户端访问网络设备的方法和网络认证服务器
TWI429256B (zh) 基於編碼證明之重新驗證的鑑定授權
JP4226665B2 (ja) ログオン証明書
US6643774B1 (en) Authentication method to enable servers using public key authentication to obtain user-delegated tickets
US7487539B2 (en) Cross domain authentication and security services using proxies for HTTP access
US7392375B2 (en) Peer-to-peer authentication for real-time collaboration
JP5265744B2 (ja) 導出鍵を用いたセキュアメッセージングシステム
US7299493B1 (en) Techniques for dynamically establishing and managing authentication and trust relationships
EP2553894B1 (fr) Autorite de certification
US20060288227A1 (en) Management of access control in wireless networks
CA2407482A1 (fr) Gestion de connexions protegees dans des reseaux dynamiques
JP2008516476A (ja) マルチメディアのグループ同報を許可する方法及びシステム
JP2006109455A (ja) 少人数グループ用プライベートネットワークのための最小限コンフィギュレーション
JP5992535B2 (ja) 無線ｉｄプロビジョニングを実行するための装置及び方法
WO2014124782A1 (fr) Procédé de preuve de fiabilité de la préservation de la confidentialité entre trois parties en communication
US20060206616A1 (en) Decentralized secure network login
WO2011063658A1 (fr) Procédé et système d&#39;authentification de sécurité unifiée
JP2008211329A (ja) セッション鍵共有システム、第三者機関装置、要求側装置、および応答側装置
WO2024116104A1 (fr) Système d&#39;identités décentralisées déléguées
JP2005217679A (ja) 通信相手の認証を行う認証サーバ
US20240121083A1 (en) Secure restoration of private key
Jaroucheh et al. Secretation: Toward a decentralised identity and verifiable credentials based scalable and decentralised secret management solution
JP4950573B2 (ja) 認証システムおよび認証方法
CN115868143B (zh) 用于将经授权的用户登录到设备上的方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23897022

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 23897022

Country of ref document: EP

Kind code of ref document: A1