ISSUING A DIGITAL CREDENTIAL FOR AN ENTITY

Description

[0001] The invention relates to a method for issuing a digital credential for an entity by an issuer computer system, an issuer computer system for issuing the digital credential, and a system comprising the issuer computer system and a requesting computer system.

[0002] In an increasingly interconnected world, secure digital identities and verifiable and thus trustworthy digital proof of identity are becoming increasingly important. Digital identities, for example, are a prerequisite for the effective design of digital business processes, digital workflows, and technical systems. At the same time, digital identities represent a security-relevant asset that therefore requires protection.

[0003] Particularly in the case of entities such as legal entities that are not natural persons, the secure issuance of digital identities represents a technical challenge. This is especially true because the respective entities are not capable of acting on their own, but rather require representatives to act on their behalf during the issuing process.

[0004] US 2021 / 365544 A1 discloses an identity integration platform that issues electronic credentials to users with a decentralized identifier based on the self-sovereign identity paradigm. However, the users are natural persons.

[0005] US 2020 / 274713 A1 also describes the concept of self-sovereign identity and also discloses a decentralized identifier.

[0024] also briefly mentions that a credential owner with a decentralized identifier (DID) can be not only a natural person, but also a legal entity, an organization, a company, or a government. However, no procedure for issuing credentials for such non-natural entities is disclosed.

[0006] The invention is therefore based on the object of providing a secure method for issuing a digital credential for an entity.

[0007] The problem underlying the invention is solved by the features of the independent patent claims. Embodiments of the invention are specified in the dependent patent claims.

[0008] Embodiments include a method for issuing a digital credential to an entity by an issuer computer system. The method comprises: Receiving an issuance request for issuing the digital credential over a network from a requesting computer system, wherein the issuance request includes a domain assigned to the requesting entity, an email address of an official representative of the entity, and a decentralized identifier. Sending a registry query for a registry entry as proof of existence of the entity over the network to a registry computer system. In response to sending the registry query, receiving a digital registry extract of the entity as proof of existence over the network from the registry computer system. Checking a link between the domain and the decentralized identifier. Sending an email with an invitation to establish an encrypted communication channel to the email address in response to sending the email.Establishing an encrypted communication channel between the issuer computer system and an ID wallet of the entity's official representative over the network, sending a request for a digital ID credential of the entity's official representative with the representative's personal attributes over the encrypted communication channel, in response to sending the request, receiving the digital ID credential over the encrypted communication channel, verifying the authenticity of the digital ID credential, checking the authority to represent the entity's official representative using the personal attributes of the digital ID credential and the entity's digital registry extract, upon a successful verification of the authority to represent, issuing the digital credential with entity-related attributes using the digital registry extract,Sending the digital credential in response to the received issuance request over the network to the requesting computer system.

[0009] Embodiments may have the advantage that digital credentials with entity-related attributes can be issued in a secure and fully automated manner even for entities that are not natural persons but rather legal persons.

[0010] The process for issuing the digital credential for an entity is initiated, for example, by the receipt of the corresponding issuance request. For example, the corresponding issuance request is a digital application form, such as an online form, which is completed by a representative of an entity to be verified and sent to the issuer computer system. Such an online form can, for example, be accessed by the requesting computer system via the Internet using a browser program, completed, and sent to the issuer computer system. For example, a system administrator of the entity to be verified completes the application form as a representative. The computer system used for this purpose is, for example, a computer system of the entity.

[0011] To verify the entity, the issuance request includes a domain assigned to the requesting entity. Such a domain is a generally visible digital presence of the entity on the Internet. This is a coherent subsection of the hierarchical Domain Name System (DNS), for example a second-level or third-level domain assigned to the entity and any associated subdomains. The issuance request also includes an email address of an official representative of the entity. An official representative of the entity is a natural person who is officially assigned to the entity as an authorized representative. The corresponding assignment is recorded in a register, such as a commercial register.For example, a relevant official representative of the entity is an executive board member, such as a managing director, a chairman or chief executive officer, such as a chairman or president of the management board of the entity, a managing director with sole signatory powers, a chief executive officer (CEO) or an authorized signatory.

[0012] A corresponding register entry for the entity may, for example, further include entity-related attributes. These entity-related attributes include, for example, one or more of the following attributes: a name under which the entity operates, an address of the entity, an indication of the legal form of the entity, a register ID of the entity, information on the name, location of the register and / or a court responsible for the register, and a founding date of the entity.

[0013] For example, the entity-related attributes included in the digital credential include entity-related attributes of the corresponding entity provided by a digital extract of a register entry of the entity. These entity-related attributes include, for example, one or more of the following attributes: a name under which the entity operates, an address of the entity, an indication of the legal form of the entity, a registry ID of the entity, information on the name, location of the registry and / or a court responsible for the registry, and a date of incorporation of the entity. For example, the entity-related attributes included in the digital credential include further entity-related attributes, such as the domain of the entity.

[0014] For example, the issuing request may further include the entity's register ID. Using the register ID, the issuing computer system can, for example, identify an entry for the entity in the register. Alternatively, the issuing computer system can execute the register query using the entity's name to check whether an entity with the corresponding name is registered in the register. Furthermore, the name can, for example, be used to identify a corresponding entry for the entity in the register.

[0015] The issuance request also includes a Decentralized Identifier (DID), i.e., a decentralized identifier of the entity. The Decentralized Identifier is an identifier according to the W3C specification (see https: / / www.w3.org / TR / did-core / ). This standard concerns the identification of a DID subject, such as an entity such as a company, without dependence on central services. A DID is an identifier that provides a verifiable, decentralized digital identity. DIDs are based on the Self-Sovereign Identity (SSI) paradigm. A DID is configured to enable a DID controller to demonstrate control over the DID and is implemented, for example, independently of a central registry, identity provider, or certification authority.DIDs are URLs that link a DID subject to a DID document, which enables trusted interactions associated with that subject. Each DID document can specify cryptographic material, verification methods, and / or service endpoints, which provide a set of mechanisms that allow the DID controller to demonstrate control over the DID. Service endpoints enable trusted interactions associated with the DID subject. A DID document includes, for example, one or more of the following: the associated DID, e.g., for self-description purposes; one or more public cryptographic keys, e.g., for verification purposes; details of one or more authentication methods, e.g., for authentication purposes; one or more service endpoints, e.g., for interaction purposes; a timestamp; / or a digital signature.

[0016] A self-determined identity enables a person, organization, or machine to create and control a digital identity without the permission of an intermediary or central party. It also enables control over how individual data is shared and / or used. For example, a user of a self-determined identity can use an ID wallet to generate decentralized identifiers (DIDs) and store verifiable credentials.

[0017] Based on the information in the issuance request, the issuing computer system can verify whether the entity for which the digital credential is being requested exists. Furthermore, the issuing computer system can verify whether the specified decentralized identifier is assigned to the entity's domain, i.e., whether the specified decentralized identifier is actually a DID of the entity. Thus, the issuing computer system can ensure that when establishing an encrypted communication channel with the entity using the DID, such as a DIDComm channel, the corresponding communication channel is actually established with the entity whose domain is specified in the issuance request.This encrypted communication channel between the issuing computer system and the entity can, for example, be used to execute a challenge-response procedure between the issuing computer system and the entity to verify whether the requesting computer system actually has control over the domain specified in the issuance request. This ensures that the requesting computer system is actually a computer system of the entity whose domain was specified. Finally, the official representative's email address can be used to establish an encrypted communication connection with a computer system of the corresponding representative or an ID wallet on a corresponding computer system. Using personal attributes from the ID wallet, the official representative can authenticate themselves to the issuing computer system.Based on the personal attributes, the issuing computer system can authenticate the entity's official representative using the registry extract. Successful authentication, for example, indicates the entity's official representative's consent to the issuance of the digital credential.

[0018] To verify the existence of the entity for which the digital credential is requested, the issuer computer system sends a register query for a register entry as proof of the entity's existence over the network to a register computer system. For example, the issuer computer system establishes an encrypted communication channel with a register computer system of the corresponding register over the network. The register query is sent, for example, over this encrypted communication channel. In response to the sending of the register query, the issuer computer system receives a digital register extract of the entity as proof of existence. The register extract is received, for example, from the register computer system over the encrypted communication channel. The existence of the entity can be digitally verified using a valid digital register extract of the entity, such as a digital commercial register extract.

[0019] Furthermore, a link between the specified domain and the issued Decentralized Identifier is checked. This check ensures that the specified Decentralized Identifier is actually a Decentralized Identifier of the entity whose domain was specified in the issuance request.

[0020] For example, the entity provides proof using the Well Known DID Configuration (see https: / / identity.foundation / .well-known / resources / did-configuration / ), which can be used to check the link between the specified DID and the domain transmitted in the issuance request. The check is carried out automatically, for example, by the issuing computer system. If the check is successful, an invitation from the issuing computer system to establish an encrypted communication channel, for example a DIDComm channel, is sent to an SSI agent of the entity. This invitation is accepted by the entity. For example, the system administrator of the entity receives a notification via a management user interface (Management User Interface / Management UI) of the entity's SSI agent about the invitation from the issuing computer system to establish the encrypted communication channel. This invitation orThe connection request can then be accepted, for example, by the entity's system administrator so that the encrypted connection channel is established.

[0021] Furthermore, the issuing computer system can, for example, verify control of the specified decentralized identifier over the specified domain. After successfully establishing the encrypted communication channel between the issuing computer system and the requesting computer system using the decentralized identifier, the issuing computer system can, for example, use a separate procedure to verify whether the requester controls the transmitted domain.

[0022] The issuer computer system then sends an email inviting the entity's official representative to establish an encrypted communication channel, which email address was provided to the issuer computer system in the issuance request. In response to the email being sent, an encrypted communication channel is established between the issuer computer system and an ID wallet of the entity's official representative over the network. For example, the encrypted communication channel is a DIDComm channel. The issuer computer system sends the invitation, for example, in the form of a machine-readable optical code, such as a QR code, to the corresponding email address. The recipient of the email, the entity's official representative, scans the machine-readable optical code using their ID wallet, such as an SSI wallet, and thereby establishes the encrypted communication channel.For example, the ID wallet of the entity's official representative is deployed on the representative's computer system. For example, the encrypted communication channel is established with an SSI agent on the issuer's computer system.

[0023] The issuer computer system sends a request for a digital ID credential to the entity's official representative via the encrypted communication channel. The digital ID credential includes personal attributes of the representative, which can be used to authenticate the representative by the issuer computer system. In response to the request, the issuer computer system receives the digital ID credential from the entity's official representative. The authenticity of the received digital ID credential is verified by the issuer computer system. For example, the digital ID credential, or the personal attributes included in the digital ID credential, are signed. For example, to verify authenticity, the issuer computer system checks the corresponding signature with a signature verification key.To authenticate the entity's official representative, the issuing computer system then checks the personal attributes of the verified digital ID credential, for example, for a match with the personal attributes of the entity's official representatives listed in the entity's register entry according to the digital register extract. If the personal attributes of the verified digital ID credential match the personal attributes of an official representative of the entity listed in the digital register extract, the official representative whose email address was provided in the issuance request is considered successfully authenticated and actually authorized to represent the entity.

[0024] For example, upon successful establishment of the encrypted communication channel, the issuer computer system requests the entity's official representative to provide proof of identity in the form of an ID credential. For example, the official representative uses a digital base ID, i.e., a digital base ID credential, to provide the ID credential, or the official representative sends the digital base ID credential as an ID credential to the issuer computer system. For example, the official representative receives the request for the digital ID credential in their ID wallet and confirms it. The digital ID credential with the requested personal attributes is then transmitted to the issuer computer system, for example, with proof of the authenticity of the digital ID credential and / or a digital base ID used to provide the digital ID credential.For example, the transmission is made to the SSI agent of the issuing computer system. The issuing computer system verifies the proof of authenticity and compares the transmitted personal attributes with the digital register extract, such as a digital commercial register extract. The verification is successful, for example, if the personal attributes can be found in a list of persons authorized to represent the entity contained in the digital register extract. For example, the proof of identity in the form of an ID credential can be based on the eID function of the electronic ID card in the form of the online ID function.

[0025] Upon successful verification of the authorization, the issuing computer system issues the requested digital credential with entity-specific attributes using the digital register extract. For example, the entity-specific attributes are extracted from the digital register extract. The resulting digital credential is sent from the issuing computer system to the requesting computer system over the network in response to the received issuance request. The issued digital credential serves, for example, as the entity's initial trust credential. The issued credential is stored, for example, by the entity's SSI agent, which may also contain an ID wallet.

[0026] For example, the entity’s issuing computer system issues the digital credential after successfully verifying the identity of the entity’s official veterinarian whose email address was provided in the issuance request. For example, after the checks have been successfully completed, the issuing computer system sends an offer to issue the digital credential to the requesting computer system. For example, the requesting computer system, e.g. a system administrator of the entity using the requesting computer system, must accept the offer as a condition for issuing the digital credential. The resulting digital credential of the entity is stored, for example, by the entity’s SSI agent and can be used to prove the identity of the entity to third parties, for example in an SSI context. Such proof can be provided by the entity ora computer system of the entity, for example, can be used in both B2C and B2B contexts.

[0027] Embodiments may have the advantage of contributing to the creation of initial trust in ecosystems between entities, such as businesses, and between entities and natural persons, such as businesses and customers, by issuing digital credentials to entities, thereby providing a foundation for collaboration between entities and between entities and natural persons in the digital space.

[0028] Embodiments may have the advantage that for validation of the entity, such as organizational or company validation, certain criteria are met, such as providing proof of the existence of the entity, verifying the applicant of the issuance request, and, if applicable, verifying the entity-related attributes included in the digital credential. Embodiments may have the advantage that the issuer computer system can provide a fully automated process for validating the entity and issuing the entity's digital credential. The process comprises the following steps: using and verifying a decentralized identifier of the company, authenticating the entity using a digital register extract, and identifying an official representative of the entity, i.e., a natural person authorized to represent the entity.The resulting verifiable digital credential can be used by the entity for authentication or as proof of identity in the digital space and confirms to the holder of the verifiable digital credential, i.e. the entity, a qualified verification of the entity and the entity-related credential provided in the verifiable digital credential by an issuer service whose issuer computer system issued the verifiable digital credential.

[0029] The process for issuing the digital credential for the entity is initiated, for example, by the issuance request, e.g., in the form of an online application. Both the entity's decentralized identifier and the entity's domain are verified by the issuing computer system. The entity's existence is verified using a digital register extract, such as a digital commercial register extract. An official representative of the entity, i.e., a natural person authorized to represent the entity, is identified. As a result, a verifiable digital credential is issued.

[0030] The following can be used as an ID credential to authenticate the official representative of the entity: Personal Identification Data from a government wallet according to the elDAS 2.0 outline, sums of qualified and non-qualified Electronic Attestation of Attributes, verifiable / anonymous credentials, such as a basic ID, attributes provided via the eID function of the new identity card or Smart eID.

[0031] The entity's digital credential can, for example, be a Verifiable Credential according to W3C, an Anonymous Credential according to Hyperledger Indy, a mobile eID (successor to mobile Driving License) according to ISO 18013-5 and ISO 23220-1, or an electronic attestation of attributes according to elDAS 2.0 Outline.

[0032] Embodiments can have the advantage that, based on the principles of Self-Sovereign Identity (SSI), a decentralized ecosystem of digital identities can also be implemented for entities that are legal entities rather than natural persons. The corresponding digital identities can be implemented in the form of digital verifiable credentials, for example, based on entity-related attributes from a digital register extract. Identity data can be read in the form of entity-related attributes in a secure and simple form from a corresponding register extract and stored as a digital verifiable credential in a wallet program or an ID wallet on an entity's computer system. For use of the digital verifiable credential based on the SSI infrastructure, a user-side computer system with the ID wallet may be sufficient.

[0033] Entity-related attributes, once stored on a computer system in the form of a digital, verifiable credential, can be used with the computer system without requiring any additional technical devices. This makes using the entity-related attributes simple and user-friendly.

[0034] A corresponding digital verifiable credential provided by a holder is checked for validity, i.e., verified, by a recipient as the verifier, for example, using the SSI infrastructure. To do this, the verifier uses the SSI infrastructure, for example, which includes a blockchain that provides the verifier with the data necessary for verification.

[0035] The digital verifiable credentials and thus the entity-related attributes can be securely stored on the computer system. For this purpose, the corresponding digital verifiable credentials are stored, for example, in an ID wallet or in a protected storage area of ​​the computer system's memory assigned to the ID wallet. In particular, storing digital verifiable credentials in an ID wallet enables the corresponding credentials to be used multiple times to securely authenticate and identify the entity to third parties.

[0036] Embodiments may have the advantage of effectively and efficiently providing digital verifiable credentials based on an SSI infrastructure in combination with an infrastructure for securely providing entity-related attributes. The entity-related attributes are used by the issuing computer system to issue a digital verifiable credential for an entity, which is stored, for example, in an ID wallet of the entity. Thus, the issued digital verifiable credential is based on entity-specific entity-related attributes.

[0037] Cryptographic key material can be securely stored on a security element of the entity's computer system. For example, the corresponding key material is stored in a security element or using a security element implemented in the form of a Secure Element (SE), an eSIM, an elUCC, and / or a TEE. The corresponding key material is used, for example, by the ID wallet to cryptographically store digital verifiable credentials. For example, digital verifiable credentials are encrypted using the key material and stored in encrypted form in the protected memory area of ​​the computer system.

[0038] Embodiments may have the advantage of enabling a secure transmission of an entity's identity data in the form of entity-related attributes, for example, by loading the entity-related attributes in the form of the digital verifiable credential into an ID wallet. For further use of the digital verifiable credential, for example, no ID provider is required. Furthermore, no additional computer program is required. Rather, the digital verifiable credential can be used by a user for the entity solely based on the computer system with the ID wallet.

[0039] Self-sovereign identities (SSI) refer to identities of a decentralized and user-centric identity infrastructure, which enables a user to have a distributed, self-determined, privacy-preserving and secure identity.

[0040] The SSI core principles include: Existence, Control, Access, Transparency, Persistence, Portability, Interoperability, Consent, Minimalization, and Protection. The core principle of existence requires that individual users have an independent existence. The core principle of control requires that users control their respective identities. The core principle of access requires that users have access to their own data. The core principle of transparency requires that systems and algorithms be transparent. The core principle of persistence requires that identities are long-lasting. The core principle of portability requires that information about and services for identities are portable.The fundamental principle of interoperability requires that identities be usable as widely as possible. The fundamental principle of consent requires that users must consent to the use of their identity. The fundamental principle of minimization requires that disclosure of claims, such as entity-related attributes, be minimized. The fundamental principle of protection requires that users' rights be protected in all cases.

[0041] Because identities and their use are placed in the hands of users, an SSI infrastructure does not include a central role such as an identity provider, which is involved in every authentication process, i.e., in every use of entity-related attributes, and thus has omniscient knowledge of user activities. In this case, for example, an identity provider is only involved in issuing digital verifiable credentials, but not in their use. Thus, the identity provider does not gain any knowledge of the use of the corresponding entity-related attributes. The same applies to issuer computer systems that issue the corresponding digital verifiable credentials. These, too, are not involved in the use of the entity-related attributes or in checking the digital verifiable credentials they issue.Instead, the verification is performed by an independent auditor using a blockchain of the SSI infrastructure. Thus, the issuing computer systems have no knowledge of the use of the entity-related attributes.

[0042] The corresponding blockchain implements the SSI infrastructure using distributed ledger technology (DLT), providing a publicly accessible and decentralized storage for audit data in the form of the blockchain, which can also guarantee the privacy of users.

[0043] In an SSI triangle, which describes the issuance and use of a digital verifiable credential, three roles are defined: issuer, holder, and verifier. The holder manages various digital verifiable credentials in a digital wallet or virtual purse. These credentials are issued by one or more issuers and typically contain claims about the holder, i.e., the entity, in the form of entity-related attributes. Such claims about the holder or entity are entity-related attributes, i.e., attributes assigned to the entity.

[0044] For example, the holder may have multiple different digital verifiable credentials with different entity-related attributes. The holder can thus independently decide which entity-related attributes to submit to a verifier for verification. Based on public verification data, such as that provided by a blockchain, the verifier can ensure the authenticity and integrity of the submitted digital verifiable credentials and thus the provided entity-related attributes. The verification data can be provided by a decentralized infrastructure based on a blockchain or a distributed ledger of the SSI ecosystem. In addition to information about the identity of the issuer and the credential schema, the verification data can also include, for example, information about revoked credentials.For example, the verification data does not include any personal data of the holder of the digital verifiable credentials. Thus, no personal data needs to be made publicly available. This allows the issuance process to be decoupled from the authentication process, as no contact with the issuer is required for the verification. As is common in the analog world, the issuer of the credentials remains unaware of their use, which represents an important contribution to user self-determination and protecting their privacy.

[0045] In contrast to the analog process, additional mechanisms, particularly technically implemented mechanisms, can be provided when using SSI to support the privacy of the holders of digital verifiable credentials. For example, data minimization can be promoted through selective disclosure of statements or entity-related attributes of a digital verifiable credential, or logical statements about corresponding entity-related attributes. Disclosure of entity-related attributes in SSI can be implemented, for example, with an interactive cryptographic proof, so that the holder is often referred to as a "prover." For each connection to an entity, a holder can, for example, appear under a new pseudonym, so that they only have to disclose as much as necessary and as little as possible about themselves, thus making unwanted traceability more difficult.Maximum control and transparency over data build user trust and can increase their acceptance of SSI-based processes. Portability and interoperability ensured by open standards, for example, can ensure the long-term sustainability of an SSI ecosystem.

[0046] Using digital credentials with entity-related attributes, SSI can also provide added value for companies or public administrations by creating a uniform standard for exchanging identity information. This standard offers a common, distributed, and thus fail-safe infrastructure and ensures simple and secure data verification without having to contact the issuer of the digital verifiable credentials used for this purpose. This can, for example, accelerate the processing of identity information in the form of corresponding digital verifiable credentials, as several digital verifiable credentials from different issuers can be verified simultaneously via an interface, thus implementing a cost-effective and streamlined data processing process. There is no need to contact multiple different issuers.Rather, the blockchain of the SSI infrastructure may be sufficient for verification.

[0047] The W3C specifies decentralized identifiers (DIDs) (see https: / / www.w3.org / TR / did-core / ) and digital verifiable credentials (VCs) (see https: / / www.w3.org / TR / vc-data-model / ). These standards enable the identification of a DID subject, i.e., an entity such as a user or organization, without dependence on centralized services. The Decentralized Identity Foundation (DIF) (see https: / / identity.foundation / ) has standardized DIDComm (https: / / github.com / decentralized-identity / DIDComm-messaging), a secure decentralized communication layer based on DIDs.

[0048] With digitally verifiable credentials, verifiable entity-related attributes can be exchanged directly between an issuer and holder or between holder and a verifier.

[0049] Embodiments can further implement a way to recall issued digital verifiable credentials. This may be necessary, for example, due to incorrectly issued or outdated data, due to misuse of the digital verifiable credential, or due to the loss of an associated private cryptographic key. Two points in particular stand out as privacy-enhancing mechanisms: Firstly, verifying the validity of a digital verifiable credential does not require a direct connection to the issuer. Instead, publicly accessible and highly available verification data from the blockchain is used. Secondly, ZKPs are also used in this context, so that correlation between different transactions by the same person is prevented during this verification as well.This can be implemented, for example, by a verification algorithm based on a cryptographic accumulator.

[0050] For the digital verifiable credentials, for example, a structure using JSON-LD is used.

[0051] An "ID token" is understood here to be a portable electronic device, for example, a chip card or a document on which a user's personal attributes, i.e., user attributes, are stored. A "document" is understood to mean, in particular, an identification, valuables, or security document, in particular a sovereign document, in particular a paper-based and / or plastic-based document, such as an electronic identification document, in particular a passport, identity card, visa, driver's license, vehicle registration document, vehicle registration document, health insurance card, or a company ID card, or another ID document, a chip card, a means of payment, in particular a banknote, bank card or credit card, a waybill, or other proof of authorization.In particular, the ID token can be a machine-readable travel document, such as that standardized by the International Civil Aviation Organization (ICAO) and / or the Federal Office for Information Security (BSI).

[0052] A security element is a secured element of a mobile device that provides cryptographic means. These cryptographic means are protected against tampering and, for example, are accessible only to authorized services and applications via cryptographic keys. In particular, the cryptographic means can only be incorporated into, supplemented, modified, and / or deleted from the security element by authorized services and applications. A security element thus provides a tamper-proof platform, for example, implemented in the form of a secure single-chip microcontroller, on which applets and / or confidential and / or cryptographic data can be stored according to predefined rules and security requirements by reliably identified trusted entities and thus made available to authorized application programs, such as an application wallet, and / or operating systems.A security element can be embedded or integrated, for example, non-destructively removable or permanently connected, i.e., not non-destructively removable. A security element can be implemented, for example, in the form of a Secure Element (SE). The security element can, for example, comprise a SIM, UICC, SmartMicroSD, smart card, eSE, eSIM, or eUICC. For example, cryptographic keys are stored on a security element, i.e., the security element comprises a data safe for cryptographic keys or a "key store." Such a key store or security element can also be implemented as part of the main processor, for example, in a TEE ("Trusted Execution Environment"). For example, the security element can be implemented using a TEE. Security elements are implemented, for example, as hardware and / or firmware. According to embodiments, security elements orKey stores can also be implemented as software. For example, two security elements are independent of each other if there is no common instance that has access rights for both security elements.

[0053] A "program" or "program instructions" is understood here, without limitation, to mean any type of computer program that contains machine-readable instructions for controlling a functionality of the computer.

[0054] A "processor" is understood here and below to mean a logic circuit used to execute program instructions. The logic circuit can be implemented on one or more discrete components, in particular on a chip. In particular, a "processor" is understood to mean a microprocessor or a microprocessor system comprising multiple processor cores and / or multiple microprocessors.

[0055] The term "memory" refers here to both volatile and non-volatile electronic memories or digital storage media.

[0056] "Non-volatile memory" is defined here as an electronic memory for the permanent storage of data, particularly static cryptographic keys, attributes, or identifiers. Non-volatile memory can be configured as non-modifiable memory, also known as read-only memory (ROM), or as modifiable memory, also known as non-volatile memory (NVM). In particular, this can be an EEPROM, for example, a Flash EEPROM, also known as Flash. Non-volatile memory is characterized by the fact that the data stored on it is retained even after the power supply is switched off.

[0057] An "interface" or "communication interface" is understood here as an interface through which data can be received and sent. The communication interface can be configured as contact-based or contactless. A communication interface can, for example, enable communication over a network. Depending on the configuration, a communication interface can, for example, provide wireless communication according to a cellular standard, Bluetooth, RFID, Wi-Fi, and / or NFC standards. Depending on the configuration, a communication interface can, for example, provide cable-based communication. The communication interface can be an internal interface or an external interface.

[0058] Encrypted communication channels, for example, are encrypted end-to-end connections. An "encrypted end-to-end connection" or an "encrypted end-to-end communication channel" is understood here as a connection between a sender and a receiver with end-to-end encryption, in which the data to be transmitted is encrypted by the sender and only decrypted again by the receiver. The encryption of transmitted data thus occurs across all transmission stations, so that intermediate stations cannot gain knowledge of the content of the transmitted data due to the encryption. The connection is cryptographically secured by encryption to prevent spying and / or manipulation of the transmission; a so-called secure messaging procedure can be used for this purpose.End-to-end encryption, for example, is based on two symmetric cryptographic keys, with a first symmetric key used to encrypt messages and a second symmetric key used to authenticate the sender of the message, for example, using Message Authentication Code (MAC) algorithms. For example, during the setup of an encrypted communication channel, ephemeral encryption keys are negotiated, which become invalid when the communication channel is terminated. Using different ephemeral keys for different communication channels makes it possible to operate multiple communication channels in parallel.

[0059] An encrypted communication channel can be established using the Transport Layer Security (TLS) protocol, for example as part of the Hypertext Transfer Protocol Secure (HTTPS) protocol.

[0060] Asymmetric key pairs are used in a variety of cryptosystems and play an important role in the secure transmission of electronic data. An asymmetric key pair consists of a public cryptographic key, which is used to encrypt and / or decrypt data and may be shared with third parties, such as a sender or receiver of data, and a private cryptographic key, which is used for encryption and / or decryption and also for signing data and must generally be kept secret. The public key allows anyone to encrypt data for the owner of the private cryptographic key or to verify digital signatures created with the private cryptographic key.A private key allows its owner to decrypt data encrypted with the public cryptographic key or to create digital signatures of data.

[0061] A digital signature of data includes, for example, creating a check value for the data, such as a hash value, which is encrypted with a private cryptographic key of an asymmetric key pair used as the signature key. In the case of a signature, only the signatory knows the private cryptographic key (i.e., signature key) of the asymmetric key pair used to create the signature. The signature recipient only has the public cryptographic key (i.e., signature verification key) of the asymmetric key pair used for the signature. The signature recipient can therefore verify the signature but cannot calculate it themselves. To verify a signature, the signature recipient calculates, for example, the check value of the signed data and compares this with the result of decrypting the signature using the signature verification key.If the calculated hash value matches the decryption result, the signature is correct. If the authenticity of the signature verification key is also confirmed, for example, by a certificate, especially a PKI certificate, the signature is valid.

[0062] A "certificate" here refers to a digital certificate, also known as a public key certificate (PKI certificate). A certificate is structured data used to assign a public cryptographic key of an asymmetric cryptosystem to an identity, such as a person, institution, or device. For cryptographic security and to prove the authenticity of the certificate data, these are signed by a certificate issuer. PKI certificates, which are based on asymmetric key pairs and, with the exception of a root certificate, are each signed by a certificate issuer with a signature key, the corresponding signature verification key of which is assigned to the certificate issuer by a PKI certificate of the corresponding certificate issuer, create a so-called public key infrastructure (PKI).For example, the certificate can conform to the X.509 standard or another standard. For example, the certificate is a Card Verifiable Certificate (CVC). An authorization certificate contains structured data that additionally defines the rights of the identity.

[0063] The PKI provides a system for issuing, distributing, and verifying digital certificates. In an asymmetric cryptosystem, a digital certificate can confirm the authenticity of a public cryptographic key and its permissible scope of use and validity. The digital certificate itself is protected by a digital signature, the authenticity of which can be verified using the public cryptographic key of the certificate issuer. A digital certificate is used to verify the authenticity of the issuer key. In this way, a chain of digital certificates can be established, each of which confirms the authenticity of the public cryptographic key, which can be used to verify the previous certificate. Such a chain of certificates forms a so-called validation path or certification path.For example, PKI participants must be able to rely on the authenticity of the last certificate, the so-called root certificate, and the key certified by it, without requiring any additional certificates. The root certificate is managed by a so-called root certification authority, whose assumed authenticity underlies the authenticity of all PKI certificates.

[0064] Digital certificates, for example, are validated by an independent, trustworthy authority (certification service provider / CSP or trust service provider / TSP), i.e., the certification authority that issued the certificate. Certificates can be made available to a wide audience to enable them to verify electronic signatures for authenticity and validity. A certificate can be associated with an electronic signature and provide a signature verification key in the form of the public cryptographic key if the private key associated with the signature verification key was used as the signature key.By making a certificate in association with a public cryptographic key available to the public, a CDA / VDA enables users of asymmetric cryptosystems to assign the public cryptographic key to an identity, for example a person, an organization, or a computer system.

[0065] A computer or computer system can be, for example, a stationary computer, such as a personal computer (PC), service terminal, or server, or a mobile, portable computer, such as a laptop, tablet, smartphone, or other smart device. The computer can include an interface for connecting to the network, which can be a private or public network, in particular the Internet. Depending on the embodiment, this connection can also be established via a mobile network.

[0066] According to embodiments, the issuance request comprises a register ID of the entity, wherein the register query comprises the register ID. Embodiments can have the advantage that, based on the register ID, it can be clearly determined which register entry in the register is to be checked as the register entry of the entity or for which register entry a digital register extract is to be requested by the issuer's computer system. For example, the register ID identifies not only the register entry in the register but also the register to be queried. For example, in addition to the register ID, additional information is included that identifies the register in which the register entry is to be queried using the register ID.

[0067] Depending on the embodiment, the issuing computer system accesses the entity's domain and reads the register ID from the domain. For example, the register ID is read from an imprint included in the domain.

[0068] According to embodiments, the register query comprises a search query for entries of the entity. Embodiments may have the advantage that, for example, no register ID needs to be specified in the issuing request. For example, the issuing computer system queries a register specified for corresponding register queries. For example, the issuing computer system itself selects a register to be queried from a predetermined plurality of registers. For example, the search query comprises a name under which the entity operates, and uses the search query to search the register for a register entry for an entity with the requested name.

[0069] According to embodiments, a plurality of register queries are sent over the network to a plurality of register computer systems. Embodiments may have the advantage of allowing the use of a plurality of registers. For example, the plurality of registers may be searched for a matching register entry of the entity.

[0070] According to embodiments, in response to the sending of the registry query, a plurality of digital registry extracts of the entity are received over the network from the plurality of registry computer systems. The digital credential with the entity-related attributes is issued using the plurality of digital registry extracts. Embodiments may have the advantage of being able to use a plurality of registries. For example, different entity-related attributes of the entity can be read from different registry extracts and used to create the digital credential.

[0071] According to some embodiments, checking the link between the domain and the decentralized identifier includes checking whether a reference to the decentralized identifier is stored under the domain. Some embodiments may have the advantage that the reference to the decentralized identifier implements a link between the domain and the decentralized identifier and can be digitally verified by the issuing computer system over the network. For example, the reference to the decentralized identifier can only be entered by an authorized domain owner.

[0072] According to embodiments, checking the link between the domain and the decentralized identifier comprises retrieving a decentralized identifier document of the decentralized identifier and checking whether the decentralized identifier document includes a reference to the domain. Embodiments may have the advantage that the reference to the domain implements a link between the domain and the decentralized identifier and is digitally verified by the issuer computer system. For example, the reference to the domain can only be entered into the decentralized identifier document by an authorized issuer of the decentralized identifier.

[0073] According to embodiments, the method further comprises checking the requesting computer system's control over the domain. Embodiments can have the advantage that this check can be used to determine whether the requesting computer system is actually a computer system of the entity whose domain is specified in the issuance request. Thus, it can be digitally verified whether the applicant using the domain for the issuance request is actually authorized to use the domain.

[0074] According to some embodiments, control is verified using a challenge-response procedure. The issuing computer system sends a challenge for publication in the domain to the requesting computer system over the network. The issuing computer system verifies the response in the form of publication in the domain. Some embodiments may have the advantage that, by publishing the challenge in the domain, the requesting computer system can prove that it has control over the domain, i.e., that it is authorized to publish data in the domain. For example, the challenge is a random value, such as a random number.

[0075] According to embodiments, the email includes the invitation to establish the encrypted communication channel in the form of a machine-readable optical code. Embodiments may have the advantage of enabling the email recipient, i.e., the official representative of the entity, to capture the invitation to establish the encrypted communication channel with their ID wallet and initiate the establishment via the ID wallet. The machine-readable optical code is, for example, a two-dimensional code, such as a QR code.

[0076] According to embodiments, the encrypted communication channel is a communication channel encrypted using end-to-end encryption. According to embodiments, the encrypted communication channel is a DIDComm channel. For example, the encrypted communication channel is a DIDComm channel, i.e., a communication channel encrypted using the DIDComm encryption protocol. A standardization on DIDComm (https: / / github.com / decentralized-identity / DIDComm-messaging), a secure decentralized communication layer based on DIDs, is provided by the Decentralized Identity Foundation (DIF) (see https: / / identity.foundation / ). Embodiments may have the advantage that the DIDComm channel provides a securely encrypted communication connection.

[0077] According to embodiments, the issuer computer system is a computer system of an issuer service of an SSI infrastructure.

[0078] An SSI stack, for example, is divided into four layers. The SSI layer model comprises public utilities or infrastructure facilities on the first, lowest layer; protocols for cryptographically secure connections, such as DIDComm peer-to-peer protocols (DIDComm Peer-to-Peer Protocol) on the second layer; data exchange protocols (Data Exchange Protocols) on the third layer; and the application ecosystem (Application Ecosystem) on the fourth, highest layer. The foundation and infrastructure are formed by a blockchain, i.e., a distributed ledger. The blockchain is operated by selected nodes and contains the public data of the participating entities. The identities of the participants are realized via decentralized identifiers (DIDs).A DID, similar to a URL, can be resolved into an identification document or DID document stored in the blockchain. Data such as service interfaces or public keys are stored in the DID document. Issuers also store metadata about credentials in the blockchain, such as schemas or revocation data.

[0079] The identities represented by DIDs can establish a cryptographically secure connection on the layer above. The protocol, standardized as "DIDComm," defines activities from connection establishment to message exchange. The DIDs and the associated key material are stored in wallets and used by corresponding computer programs or software agents.

[0080] Layer three is where the actual exchange and connection between the three parties of the SSI ecosystem takes place. Issuers or verifiers are in direct contact with the holder; the issuer issues digital, verifiable credentials to the holder, which can be requested by the verifier and presented by the holder. Trust between verifier and issuer is indirectly represented via the network.

[0081] Finally, the fourth layer represents the application of SSI technology, for example, in business processes, government procedures, and other proof of identity and authentication. The technical SSI stack is accompanied by an organizational and legal framework that defines the rules of the SSI network and clarifies the legal and regulatory connection to the real world.

[0082] SSI enables the provision of an interoperable and reusable layer for identification and authentication processes. For example, the operation of the SSI infrastructure can be ensured by a fixed group of network operators and through organizational and technical measures. To serve as a solid foundation for the participants involved, e.g., issuers, holders, and verifiers, the SSI infrastructure fulfills, for example, the following properties in particular: It ensures the incorruptibility and / or unambiguous assignment of transactions in the blockchain to their author, thus guaranteeing the authenticity of the data. Verifiability of the current state of the blockchain can ensure the integrity of the data provided by the blockchain.Even with multiple faulty node operators, the reliability of the blockchain network can be ensured, thus ensuring the availability, redundancy, and robustness of data storage. Since the verification data stored in the blockchain, for example, publicly accessible verification data, is non-personal verification data that is intended to be publicly accessible and attributable to a public entity, confidentiality and anonymity are irrelevant in this regard.

[0083] The SSI infrastructure used, for example, includes a public, permissioned blockchain. This ledger technology combines features of public, permissionless blockchain variants, such as Bitcoin and Ethereum, with features of private, permissioned blockchain variants, such as R3 Corda and Hyperledger Fabric. The blockchain network comprises several blockchain servers, which serve, for example, as network nodes or validator nodes. These are operated by specially authorized or appointed actors ("stewards") in a permissioned blockchain network. The network nodes establish trust among themselves, for example, by using a consensus algorithm.For example, consensus can be formed using the Plenum protocol, a Redundant Byzantine Fault Tolerance algorithm (RBFT), which is a redundant version of the PBFT, which has been evaluated as secure. This algorithm requires a maximum number F of malicious or faulty network nodes, resulting in a total number N = 3F + 1 of nodes in the blockchain network. A reasonable size for a blockchain network includes, for example, 25 network nodes and / or around 25 network nodes, so that good resilience is guaranteed and the corresponding consensus algorithm can operate as efficiently as possible. The efficiency of RBFT and the high throughput with low resource requirements correspond to the advantages of a permissioned blockchain.

[0084] A public permissioned ledger or blockchain network, for example, can represent an identity network that advantageously promotes user privacy. Since the ledger or blockchain only stores public information from issuers and verifiers, especially institutional issuers and verifiers, but no user-related data, it can effectively solve classic DLT problems such as scaling, efficiency, and energy consumption.

[0085] For example, read access to the blockchain network or the blockchain provided by the blockchain network is freely accessible and does not require authentication, similar to the typical characteristics of a public blockchain. However, write access is subject to authorization and requires not only the author's signature but also the consent of an authorized approver ("endorser"). As an initial transaction, an author creates their DID and deposits their derived public cryptographic key. The author signs all subsequent transactions themselves with their associated private cryptographic key, thus ensuring the authenticity of the data and making it easily verifiable. The author sends the resulting transactions to several network nodes of the blockchain network, and as soon as they have received more than F + 1 positive responses, finality or consistency is achieved.In a corresponding blockchain network, consensus on the relevant data can be stored, for example, using a Boneh-Lynn-Shacham (BLS) multi-signature, which proves the unambiguous consistency of the network nodes, so that only a single node needs to be consulted for a read request. The stored transactions are stored, for example, as an ordered list with a Merkle tree. The correct state of the blockchain can be verified using a current state proof and an audit trail of the Merkle tree. The authenticity of the authorized approvers can be ensured, for example, using their assigned public cryptographic keys from a genesis file of the blockchain network.

[0086] To enforce the rules of the permissioned blockchain network, the blockchain is assigned its own configuration and an integrated rights and rules system. This system includes, for example, the following: A trustee manages the rights of other members and can define the rules. An actor ("steward") operates a network node. An endorser confirms write access for regular data transactions. A network monitor monitors and analyzes the metadata for proper network operation.

[0087] For example, an issuer's DID is stored in the blockchain or blockchain network together with the issuer's public cryptographic key. The issuer's identity can therefore be verified within the blockchain network using these public cryptographic keys. Technical measures can be used to ensure the incorruptibility of issued data or a digitally verifiable credential, i.e., its integrity and authenticity. A verifier verifies the incorruptibility by validating the issuer's signature. For this purpose, a signature scheme that supports Zero Knowledge Proof (ZKPs), such as the Camenisch-Lysyanskaya or BBS+ signature scheme, can be used. Within the scope of such a signature verification, the verifier only learns that the holder demonstrates knowledge of a valid signature of the disclosed entity-related attributes.This can, for example, support selective disclosure and / or logical statements.

[0088] According to embodiments, the method further comprises using the digital credential by the requesting computer system. Using the digital credential comprises sending the digital credential to an authenticating computer system during the process of authenticating the entity to the authenticating computer system. Embodiments may have the advantage that the requesting computer system can authenticate itself to the authenticating computer system using the digital credential. For example, the requesting computer system verifies the identity of the entity to an authenticating computer system using the digital credential.

[0089] In the case of mutual authentication, the method further comprises, for example, receiving a digital credential from the authenticating computer system by the requesting computer system via the network and verifying the received digital credential

[0090] Embodiments include an issuer computer system for issuing a digital credential to an entity. The issuer computer system includes a first processor, a first memory with first program instructions, and a first communication interface for communication over a network.

[0091] Execution of the first program instructions by the first processor of the issuer computer system causes the first processor to control the issuer computer system to: Receiving an issuance request for issuing the digital credential over a network from a requesting computer system, wherein the issuance request includes a domain assigned to the requesting entity, an email address of an official representative of the entity, and a decentralized identifier; sending a registry query for a registry entry as proof of existence of the entity over the network to a registry computer system; receiving a digital registry extract of the entity as proof of existence over the network from the registry computer system; checking a link between the domain and the decentralized identifier; sending an email with a request to establish an encrypted communication channel to the email address in response to the email; establishing an encrypted communication channel between the issuing computer system and an ID wallet of the official representative of the entity over the network;Sending a request for a digital ID credential of the entity's official representative with the representative's personal attributes via the encrypted communication channel. In response to sending the request, receiving the digital ID credential via the encrypted communication channel. Verifying the authenticity of the digital ID credential. Checking the authority to represent the entity's official representative using the personal attributes of the digital ID credential and the entity's digital register extract. Upon successful verification of the authority to represent, issuing the digital credential with entity-related attributes using the digital register extract. Sending the digital credential in response to the received issuance request via the network to the requesting computer system.

[0092] Embodiments of the issuer computer system are configured to perform each of the aforementioned steps of the embodiments of the method for issuing a digital credential for an entity performed by the issuer computer system.

[0093] Embodiments include a system comprising an issuer computer system according to any one of the aforementioned embodiments and a requesting computer system. The requesting computer system includes a second processor, a second memory with second program instructions, and a second communication interface for communication via the network.

[0094] Execution of the second program instructions by the second processor of the requesting computer system causes the second processor to control the requesting computer system to: Creating the issuance request to issue the digital credential, sending the issuance request over the network to the issuer computer system, in response to the sent issuance request, receiving the digital credential over the network from the issuer computer system.

[0095] According to embodiments, the requesting computer system for storing the received digital credential comprises an SSI agent, which may, for example, comprise an ID wallet for storing the digital credential.

[0096] According to embodiments, the execution of the second program instructions by the second processor of the requesting computer system further causes the second processor of the requesting computer system to use the received digital credential. Using includes sending the digital credential to an authenticating computer system in the course of authenticating the entity to the authenticating computer system.

[0097] Embodiments of the invention will be explained in more detail below with reference to the drawings. They show: Figures 1A, B shows a schematic flow diagram of an exemplary method for issuing a digital credential for an entity, Figure 2 shows a schematic flow diagram of an exemplary method for issuing a digital credential for an entity, Figure 3 shows a schematic block diagram of an exemplary issuance request, Figure 4 shows a schematic block diagram of an exemplary invitation to establish an encrypted communication channel, Figure 5 shows a schematic block diagram of an exemplary system for issuing a digital credential for an entity, Figure 6 shows a schematic block diagram of another exemplary system for issuing a digital credential for an entity, Figure 7 shows a schematic flow diagram of an exemplary method for using a digital credential, Figures 8A,Figure 9 is a schematic block diagram of another exemplary system for issuing a digital credential for an entity, Figure 10 is a schematic flow diagram of an exemplary method for requesting a digital credential for an entity, Figure 11 is a schematic flow diagram of an exemplary method for authenticating using a digital credential, and Figure 12 is a schematic flow diagram of an exemplary method for authenticating using a digital credential.

[0098] Elements of the following embodiments that correspond to one another are identified by the same reference numerals.

[0099] Figure 1 , which consists of the Figures 1A and 1Bshows an exemplary method for issuing a digital credential for an entity by an issuer computer system. In block 10, the issuer computer system receives an issuance request for issuing the digital credential over a network from a requesting computer system. For example, the issuance request is an online form that is completed by a representative of the verifying entity and sent to the issuer computer system. The representative of the verifying entity uses, for example, a browser or a standalone application on their computer system that is configured to request digital credentials. The issuance request includes a domain assigned to the requesting entity, an email address of an official representative of the entity, and a decentralized identifier.For example, the issuance request additionally includes a register ID of a register entry of the entity in a register, such as a commercial register. In block 12, the issuer computer system sends a register query for a register entry of the entity as proof of existence of the entity over the network to a register computer system. For example, the issuer computer system identifies the corresponding register entry in the register query using the register ID. For example, the register query includes a search request, for example for a name under which the entity trades, in order to identify the register entry. In block 14, the issuer computer system receives a digital register extract of the entity as proof of existence over the network from the register computer system. In block 16, the issuer computer system checks a link between the domain and the decentralized identifier.To do this, the issuer computer system checks, for example, whether a reference to the decentralized identifier is stored under the domain. For example, the issuer computer system calls up a decentralized identifier document of the decentralized identifier and then checks whether it contains a reference to the domain. In block 18, the issuer computer system optionally checks whether the requesting computer system has control over the domain. This control check is carried out, for example, using a challenge-response procedure. The issuer computer system sends a challenge for publication in the domain over the network to the requesting computer system and checks the response in the form of publication in the domain. If the challenge, e.g., a random value, is published in the domain, this represents successful proof of the requesting computer system's control over the domain.If the challenge is not published in the requested domain, the challenge-response procedure is used, meaning the requesting computer system has no control over the domain. In block 20, the issuing computer system sends an email with a request to establish an encrypted communication channel to the email address of the entity's official representative. For example, the email contains the invitation in the form of a machine-readable optical code, such as a QR code. In block 21, in response to the email being sent, an encrypted communication channel is established between the issuing computer system and an ID wallet of the entity's official representative over the network. The encrypted communication channel is, for example, a DIDComm channel.

[0100] In block 24, the issuer computer system sends a request for a digital ID credential of the entity's official representative with the representative's personal attributes over the encrypted communication channel. In block 26, in response to the request, the issuer computer system receives the digital ID credential over the encrypted communication channel, the authenticity of which the issuer computer system verifies in block 28. In block 30, the issuer computer system checks the authority to represent the entity's official representative using the personal attributes of the verified digital ID credential and the entity's digital registry extract.If the personal attributes stated in the verified digital ID credential match the personal attributes of a representative stated in the digital register extract, the official representative whose email address was stated in the issuance request is indeed an authorized representative.

[0101] In block 32, upon successful verification of the authorization to represent, the issuing computer system issues the digital credential with entity-related attributes using the digital register extract. For example, the entity-related attributes included in the digital credential are taken entirely or partially from the digital register extract. For example, the included entity-related attributes include, in addition to the entity-related attributes taken from the digital register extract, an indication of the entity's domain. In block 34, the issuing computer system sends the digital credential to the requesting computer system over the network in response to the received issuance request.

[0102] Figure 2shows an exemplary method for issuing a digital credential for an entity. The method for issuing the digital credential for an entity is initiated in step 40, for example, by the receipt of a corresponding issuance request from a requesting computer system 150 of the entity by an issuer computer system 100 of an issuer service. For example, the corresponding issuance request is a digital application form, such as an online form, which is completed by a representative of an entity to be verified and sent to the issuer computer system 100. For example, a system administrator of the entity to be verified fills out the application form as a representative. The computer system 150 used for this purpose is, for example, a computer system of the entity.

[0103] To verify the entity, the issuance request includes a domain assigned to the requesting entity. Such a domain is a generally visible digital presence of the entity on the Internet. The issuance request also includes an email address of an official representative of the entity. An official representative of the entity is a natural person who is officially assigned to the entity as an authorized representative. A corresponding assignment is recorded in a register, such as a commercial register. A corresponding register entry for the entity can, for example, further include entity-related attributes.These entity-related attributes include, for example, a name under which the entity operates, an address of the entity, an indication of the legal form of the entity, a registry ID of the entity, information on the name, location of the registry and / or a court responsible for the registry, and the date of establishment of the entity. Furthermore, the issuance request includes a Decentralized Identifier (DID).

[0104] For example, the issuing request may further include the entity's register ID. Using the register ID, the issuing computer system 100 can, for example, identify an entry for the entity in the register. Alternatively, the issuing computer system 100 can execute the register query using the entity's name to check whether an entity with the corresponding name is registered in the register. Furthermore, the name can be used to identify the entity's entry in the register, for example.

[0105] Based on the information in the issuance request, the issuing computer system 100 can verify in step 42 whether the entity for which the digital credential is requested exists. To do so, the issuing computer system 100 sends a corresponding register query to a register computer system 250, which provides the register to be queried in digital form. Furthermore, the issuing computer system 100 can verify in step 44 whether the specified decentralized identifier is assigned to the entity's domain, i.e., whether the specified decentralized identifier is actually a DID of the entity.Thus, the issuing computer system can ensure that when establishing an encrypted communication channel in step 46 with the requesting computer system 150 of the entity using the DID, such as a DIDComm channel, the corresponding communication channel is actually established with the SSI agent of the entity whose domain is specified in the issuance request. This encrypted communication channel between the issuing computer system 100 and the requesting computer system 150 of the entity can be used in step 48 to verify whether the requesting computer system 150 actually has control over the specified domain. For example, the encrypted communication channel is used to execute a challenge-response procedure between the issuing computer system 100 and the requesting computer system 150 of the entity.The challenge-response method is used to check whether the requesting computer system actually has control over the domain specified in the issuance request. This ensures that the requesting computer system 150 is actually a computer system of the entity whose domain was specified. Finally, the email address of the official representative can be used in step 50 to establish an encrypted communication connection with a computer system 200 of the corresponding representative or an ID wallet on a corresponding computer system 200. Using personal attributes from the ID wallet, the official representative can authenticate himself to the issuer computer system 100 in step 54 in response to a corresponding request from the issuer computer system 100 in step 52. In step 56, the authenticity of the ID credential orthe personal attributes of the official representative included in the ID credential are verified. Based on the verified personal attributes, the issuing computer system 100 can authenticate the entity's official representative using the register extract in step 58. Successful authentication proves the authority to represent the official representative whose email address was used in the issuance request. Through successful authentication, the entity's official representative, for example, further indicates their consent to the issuance of the digital credential. Upon successful verification of authority to represent, the requested entity's digital credential with entity-related attributes is issued by the issuing computer system 100 using the digital register extract in step 60 and sent to the requesting computer system 150 via the network.The issuance can, for example, be made to the entity's SSI agent, which may also include an ID wallet for storing the issued digital credential.

[0106] To verify the existence of the entity for which the digital credential is requested, the issuer computer system 100 sends a register query for a register entry as proof of the entity's existence over the network to a register computer system 250 in step 42. For example, the issuer computer system 100 establishes an encrypted communication channel with a register computer system 250 of the corresponding register over the network. The register query is sent, for example, over this encrypted communication channel. In response to the sending of the register query, the issuer computer system 100 receives a digital register extract of the entity as proof of existence. The register extract is received, for example, over the encrypted communication channel from the register computer system 250. The existence of the entity can be digitally verified using a valid digital register extract of the entity, such as a digital commercial register extract.

[0107] Furthermore, in step 44, a link between the specified domain and the issued Decentralized Identifier is checked. Such a check can ensure that the specified Decentralized Identifier is actually a Decentralized Identifier of the entity whose domain was specified in the issuance request.

[0108] For example, using the Well Known DID Configuration (see https: / / identity.foundation / .well-known / resources / did-configuration / ), the entity provides proof that can be used to verify the link between the specified DID and the domain transmitted in the issuance request. The verification is performed automatically, for example, by the issuing computer system 100. If the verification is successful, an invitation from the issuing computer system 100 to establish an encrypted communication channel, for example, a DIDComm channel, is sent to an SSI agent of the entity. This invitation is accepted by the entity.For example, the entity's system administrator receives a notification of the invitation from the issuing computer system 100 to establish the encrypted communication channel via a management user interface (Management User Interface / Management UI) of the entity's SSI agent on the requesting computer system 150. This invitation or connection request can then be accepted, for example, by the entity's system administrator so that the encrypted connection channel is established.

[0109] Furthermore, in step 48, the issuer computer system 100 can, for example, check whether the specified decentralized identifier controls the specified domain. After successfully establishing the encrypted communication channel between the issuer computer system 100 and the requesting computer system 150 using the decentralized identifier, the issuer computer system 100 can, for example, check using one of the previously described methods whether the requester controls the transmitted domain.

[0110] Subsequently, in step 50, the issuer computer system 100 sends the email with the invitation to establish an encrypted communication channel to the email address of the entity's official representative, which was transmitted in the issuance request to the issuer computer system 100. The official representative can access the email on a representative computer system and agree to the establishment. In response to the sending of the email, the encrypted communication channel between the issuer computer system 100 and an ID wallet of the entity's official representative is established via the network. For example, the encrypted communication channel is a DIDComm channel. The issuer computer system 100 sends the invitation, for example, in the form of a machine-readable optical code, such as a QR code, to the corresponding email address. The recipient of the email, i.e.The entity's official representative, for example, scans the machine-readable optical code using their ID wallet, such as an SSI wallet, and thereby establishes the encrypted communication channel. The entity's official representative's ID wallet is provided, for example, on a computer system 200 of the respective representative. For example, the encrypted communication channel is established to an SSI agent of the issuer computer system 100.

[0111] In step 52, the issuer computer system 100 sends a request for a digital ID credential to the entity's official representative or its representative computer system 200 via the encrypted communication channel. The digital ID credential includes personal attributes of the representative, which can be used to authenticate the representative by the issuer computer system 100. In response to the request, the issuer computer system 100 receives the entity's official representative's digital ID credential from the representative computer system 200 in step 54. In step 56, the authenticity of the received digital ID credential is verified by the issuer computer system 100. For example, the digital ID credential or the personal attributes included in the digital ID credential are signed.For example, to verify authenticity, the issuer computer system 100 checks the corresponding signature with a signature verification key. The personal attributes of the verified digital ID credential are then checked in step 58 for authentication of the entity's official representative by the issuer computer system 100, for example, for a match with personal attributes of official representatives of the entity, which are entered in the entity's register entry according to the digital register extract. If the personal attributes of the verified digital ID credential match the personal attributes of an official representative of the entity listed in the digital register extract, the official representative whose email address was specified in the issuance request is considered successfully authenticated and actually authorized to represent the entity.

[0112] For example, in step 52, upon successful establishment of the encrypted communication channel, the issuer computer system 100 requests the entity's official representative for proof of identity in the form of the ID credential. For example, the official representative uses a digital base ID, i.e., a digital base ID credential, to provide the ID credential, or the official representative sends the digital base ID credential as an ID credential to the issuer computer system 100. For example, the official representative receives the request for the digital ID credential in their ID wallet and confirms it. The digital ID credential with the requested personal attributes is then transmitted to the issuer computer system 100 in step 54, for example, with proof of the authenticity of the digital ID credential and / or a digital base ID used to provide the digital ID credential.For example, the transmission is made to the SSI agent of the issuing computer system 100. The issuing computer system 100 verifies the proof of authenticity in step 56 and compares the transmitted personal attributes with the digital register extract, for example, a digital commercial register extract, in step 58. The verification is successful, for example, if the personal attributes can be found in a list of persons authorized to represent the entity contained in the digital register extract. For example, the proof of identity in the form of an ID credential can be based on the eID function of the electronic ID card in the form of the online ID function.

[0113] Following the successful verification of the authorization to represent in step 58, the issuing computer system 100 issues the requested digital credential with entity-related attributes in step 60 using the digital register extract. For example, the entity-related attributes are taken from the digital register extract. The resulting digital credential is sent from the issuing computer system 100 in response to the received issuance request via the network to the requesting computer system 150. The issuance can, for example, be made to the entity's SSI agent, which can also include an ID wallet for storing the issued digital credential. The issued digital credential serves, for example, as the entity's initial trust credential.

[0114] For example, the entity's issuing computer system 100 issues the digital credential in step 60 after successfully verifying the identity of the entity's official veterinarian in step 58, whose email address was specified in the issuance request. For example, after successfully completing the verifications, the issuing computer system 100 sends an offer to issue the digital credential to the requesting computer system 150. For example, the requesting computer system 100, e.g., a system administrator of the entity using the requesting computer system 150, must accept the offer as a prerequisite for the issuing computer system 100 to issue the digital credential. The entity's resulting digital credential is stored, for example, by the entity's SSI agent and can be used, for example, in an SSI context, to prove the entity's identity to third parties.Such proof can be used by the entity or a computer system of the entity, for example, in both B2C and B2B contexts.

[0115] Figure 3 shows an exemplary issuance request 600, for example in the form of an online form, which the requesting computer system fills out. The issuance request 600 includes a register ID assigned to the requesting entity, which identifies a register entry of the entity in a register, a domain assigned to the requesting entity, an email address of an official representative of the entity, and a decentralized identifier (DID) of the entity.

[0116] Figure 4shows an email 602 from an issuer computer system with an invitation 604 to establish an encrypted communication channel between the issuer computer system and a computer system of the official representative of the entity, to whose email address the email 602 is sent. The email 602 contains the invitation 604 to establish the encrypted communication channel, such as a DIDComm channel, in the form of a machine-readable optical code, for example, a QR code. To establish the encrypted communication channel, the official representative of the entity can scan the machine-readable optical code, for example, with their ID wallet.

[0117] Figure 5shows an exemplary system 101 configured to provide digital verifiable credentials for entities through an issuer computer system 100. The digital verifiable credentials include entity-related attributes from registries, such as the registry provided by registry computer system 250. The issuer computer system 100 includes an issuer program 302 for issuing digital verifiable credentials for entities. Furthermore, the system 101 has a blockchain 400 of an SSI infrastructure, in which digital verifiable credentials and public cryptographic keys of the SSI infrastructure are stored, which are assigned to issuers of verifiable credentials. The system 101 also includes a requesting computer system 150 of an entity, through which an issuance request for issuing a digital credential for the entity can be submitted to the issuer computer system 100.For example, the issuance request is an online form that is completed using a browser 156. Furthermore, the system 101 comprises a domain server 300, which provides the contents of an entity's domain for retrieval, for example, via the Internet. Finally, the system 101 comprises a representative computer system 200 with an email client 206 for receiving an email with an invitation to establish an encrypted communication channel between the issuer computer system 100 and the representative computer system 200. Furthermore, the representative computer system 200 comprises an ID wallet 202 with a protected storage area 204 in which ID credentials and / or verifiable personal attributes of the entity's representative 201 are stored. The representative 201 uses these ID credentials and / or verifiable personal attributes to authenticate to the issuer computer system 100.For this purpose, the representative computer system 200 sends an ID credential, which is stored, for example, in the protected storage area 204 or which is derived, for example, from the ID credentials and / or verifiable personal attributes stored in the protected storage area 204, to the issuer computer system 100. The issuer computer system 100 verifies the authenticity of the received ID credential and checks the authorization to represent the representative 201 by comparing the personal attributes included in the credential used by the official representative 201 of the entity with personal attributes of the representative of the entity, which are mentioned in a digital register extract.If all data provided in the issuance request have been successfully checked for their validity and their assignment to the specified entity, the issuer computer system issues a digital credential for the requesting entity using the issuance program 102.

[0118] The service for issuing digital verifiable credentials for entities issued by the issuer computer system 100 is, for example, an issuer service of an SSI infrastructure. The SSI infrastructure used by the issuer service includes, for example, the blockchain 400. The blockchain 400 provides, for example, data schemas for issuing digital verifiable credentials. These data schemas describe the structural design of the corresponding digital verifiable credentials. Furthermore, public cryptographic keys of issuers of the SSI infrastructure are stored in the blockchain 400. Thus, the blockchain 400, which is, for example, a public permissioned blockchain in which write access is restricted while read access is possible for everyone, enables the verification of a digital verifiable credential.For this purpose, for example, a read access to the blockchain 400 is performed and the data schema stored for the corresponding credential, as well as the public cryptographic key of the issuer of the credential to be verified, are read out. Using the corresponding data schema, it can be checked whether the existing digital verifiable credential has the stored structure and includes all data types necessary for successful verification. For example, the data types necessary for verification include certain types of entity-related attributes, which are stored, for example, in the entity's register entry. Furthermore, the stored public cryptographic key of the issuer can be used to verify the signature of the digital verifiable credential.

[0119] Furthermore, revocation notices, for example, can be stored in the blockchain 400, which inform about a revocation of an issued digital verifiable credential. During the verification of an existing digital verifiable credential, the blockchain 400 can be used to check whether a revocation entry is stored in the blockchain for the corresponding credential. If a revocation entry is stored in the blockchain, i.e., if the corresponding credential is revoked, the result of a verification of the corresponding credential is negative. Finally, parameters for authenticating communication participants can be stored in the blockchain 400. For example, based on the corresponding authentication information, the ID wallet 202 and the issuer program 102 can be authenticated during the establishment of the encrypted communication channel.

[0120] If the verifiable credential of the entity is issued and securely stored, for example, in an ID wallet 102 of the entity, the entity or its computer system 150 can use the corresponding digital credential for authentication or identification. For this purpose, the digital credential, for example, is sufficient. With the digital credential, the entity can identify itself to any other entity. This works digitally, in particular, in that the entity, if necessary, selects a suitable digital verifiable credential, for example, from the ID wallet, and sends it to the other entity. The receiving entity, i.e., a verifier, can verify the received digital verifiable credential, for example, using the blockchain 400.To do so, the verifier checks, for example, in the manner described above, whether the presented digital verifiable credential is valid using the information contained in the blockchain 400, such as the data schema, the public cryptographic key, and / or hints. If the verification is successful, the digital verifiable credential is recognized as authentic, and the associated entity is considered authenticated based on the entity-related attributes provided by the digital verifiable credentials.

[0121] Figure 6 shows another exemplary system 101 configured to provide digital verifiable credentials to entities through an issuer computer system 100. In addition to the components of the Figure 5 The system 101 shown comprises the system 101 of the Figure 6Furthermore, an ID provider computer system 500 for reading personal attributes of the entity's official representative 201 from an ID token 502. These personal attributes are provided to the issuer computer system 100 as ID credentials for authenticating the representative 201 and verifying their authorization to represent the entity. The issuer computer system 100 uses the ID provider computer system 500 to read personal attributes from the ID token 502. For this purpose, the ID provider computer system 500 comprises, for example, authorization credentials that enable it to read personal attributes from the ID token 502. The issuer computer system 100 requests the read personal attributes from the ID provider computer system 500, for example, using the utility program 104.The reading of personal attributes from the ID token 502 occurs, for example, through an ID client program 208 running on the representative computer system 200. The ID provider computer system 500 provides the personal attributes to the issuer computer system 500. For example, the personal attributes provided by the ID provider computer system 500 are signed with a signature key of the ID provider computer system 500, thereby proving their authenticity. The issuer computer system 100 uses the read personal attributes of the representative 201 to verify the representative.

[0122] Figure 7 illustrates a use of a digital verifiable credential 110 by an entity that is the holder of the digital verifiable credential 110. The digital verifiable credential 110 was created, for example, according to one of the methods of one of the Figures 1 or 2issued. The entity has a computer system 150 on which the digital verifiable credential 110 is securely stored, for example, in an ID wallet. The entity receives the corresponding digital verifiable credential 110 from an issuer or an issuer computer system 100. The entity can use the thus issued digital verifiable credential with a verifier or a verification computer system 700. To do so, the entity sends the digital verifiable credential 110, for example, from the computer system 150 to the verifier's verification computer system 700. The verifier verifies the provided digital verifiable credential 110, for example, using an SSI infrastructure that includes a blockchain 400. For example, authentication information 402 for authenticating the issuer 100 and the verifier 700 is stored in the blockchain 400.Furthermore, public cryptographic keys 404 of the issuer 100 are stored in the blockchain 400, for example, using these keys as signature verification keys to verify a signature of the digital verifiable credential 110. Furthermore, data schemas 406 that define structures of the digital verifiable credential 110 are stored in the blockchain 400. Using the stored data schema 406, it can be checked whether the digital verifiable credential 110 has the intended data structure and, in particular, whether the digital verifiable credential 110 includes the entity-related attributes it should include. Furthermore, revocation data 408 that define a revocation of an issued digital verifiable credential can be stored in the blockchain 400.For example, information about where a corresponding revocation notice of a digital verifiable credential is stored can be stored in the blockchain 400, or a corresponding revocation notice itself can be stored in the blockchain 400. Thus, using the blockchain 400, the validity of a presented digital verifiable credential 110 can be checked by a verification computer system 700. If the validity check is positive and the credential is thus verified, the data provided by it, in particular the entity-related attributes of the corresponding entity, are accepted as authentic by the verification computer system 700. Thus, the entity can authenticate and / or identify itself to the verification computer system 700 using the digital verifiable credential 110.The blockchain 400, for example, is a public blockchain requiring approval, in which write access, for example by the issuer computer system 100, is only possible with a corresponding authorization, while anyone else, such as the verification computer system 700, can read the blockchain 400 and its entries.

[0123] Figure 8 , which consists of the Figures 8A and 8B shows an exemplary system 101 for issuing and providing a digital verifiable credential for an entity. Based on the exemplary system 101 of Figure 8 Each of the exemplary systems 101 may be configured according to the Figures 5 and 6 be implemented. The Figure 8 shown system 101 for performing each of the exemplary methods of Figures 1 , 2 , 9, 10 and 11 be used. The Figure 8The exemplary system 101 shown includes an issuer computer system 100, a requesting computer system 150 of an entity for which a digital credential is to be issued, a computer system 200 of an official representative of the entity, a registry computer system 250 providing a registry, a domain server 300 providing content of a domain of the entity, a blockchain network 450 providing a blockchain 400, and a network 103.

[0124] The issuer computer system 100 is configured to issue digital verifiable credentials for entities. Programs 114 are stored in a memory 112 of the issuer computer system 100. These programs include, for example, an issuer program for issuing the digital verifiable credentials and / or a revocation program for revoking issued digital verifiable credentials. Furthermore, a public cryptographic key 118 is stored in the memory 112 as the signature verification key of the issuer computer system 100. A corresponding private cryptographic key 122 as the signature key of the issuer computer system 100 for signing digital verifiable credentials is stored, for example, in a protected memory area 120 of the memory 112. The issuer computer system 100 also includes a processor 124 configured to execute program instructions 126 of the programs 114.By executing the program instructions 126 by the processor 124, the issuer computer system 100 is controlled to issue digital verifiable credentials. For this purpose, the issuer computer system further includes a communication interface 128 for communication via the network 103, for example, with the requesting computer system 150 of the entity, the computer system 200 of the entity's official representative, the registry computer system 250, the domain server 300, and / or the blockchain network 450.

[0125] The requesting computer system 150 of the entity is configured to create and send an issuance request for issuing a digital verifiable credential for the corresponding entity. Programs 154 are stored in a memory 152 of the requesting computer system 150. These programs 154 include, for example, a browser for accessing and completing an issuance request in the form of an online form. These programs 154 also include, for example, a program for controlling and modifying content of a domain of the entity, which is provided, for example, by the domain server 300. Furthermore, the requesting computer system 150 includes a processor 156 configured to execute program instructions 128 of the programs 154. Execution of the program instructions 158 by the processor 156 controls the requesting computer system 150 to submit the issuance request.For this purpose, the issuer computer system further comprises a communication interface 162 for communication via the network 103, for example with the issuer computer system 100, the domain server 300 and / or the blockchain network 450. Furthermore, the requesting computer system 150 comprises a user interface 164, which enables a user, such as a system administrator of the entity, to interact with the requesting computer system 150 and to control its functions.

[0126] The representative computer system 200 of an official representative of the entity is configured to authenticate the representative to the issuer computer system 100. Programs 214 are stored in a memory 212 of the representative computer system 200. These programs 214 include, for example, an ID wallet with ID credentials and / or verifiable personal attributes of the representative, with which the representative can authenticate themselves to the issuer computer system 100. Furthermore, these programs 214 include, for example, an email client for receiving emails, for example, with an invitation from the issuer computer system 100 to establish an encrypted communication channel. Furthermore, the representative computer system 200 includes a processor 216 configured to execute program instructions 218 of the programs 214.By executing the program instructions 218 by the processor 214, the representative computer system 200 is controlled, for example, to establish an encrypted communication channel with the issuer computer system 100 and to authenticate the official representative of the entity to the issuer computer system 100. For this purpose, the representative computer system 200 further comprises a communication interface 222 for communication via the network 103, for example, with the issuer computer system 100. Furthermore, the representative computer system 200 comprises a user interface 224, which enables the official representative of the entity to interact with the representative computer system 200 and control its functions.

[0127] Register computer system 250 is configured to provide digital register extracts of register entries in a digital register, such as a commercial register. Register entries 254 of the digital register are stored in a memory 252 of register computer system 250. Register computer system 250 also includes a processor 256 configured to execute program instructions 258. Execution of program instructions 258 by processor 256 controls register computer system 250 to provide digital register extracts. For this purpose, register computer system 250 further includes a communication interface 262 for communication via network 103, for example, with issuer computer system 100.

[0128] The domain server 300 is configured to provide a domain 304 of the entity. For example, the corresponding contents of the domain 304 are stored in a memory 302 of the domain server 300. Furthermore, the domain server 300 comprises a processor 306 configured to execute program instructions 308. Execution of the program instructions 308 by the processor 306 controls the domain server 300 to provide the contents of the domain 304 of the entity. For this purpose, the domain server 300 further comprises a communication interface 312 for communication via the network 103, for example, with the issuing computer system 100 and / or the requesting computer system 150 of the entity.

[0129] Finally, the system 101 comprises the blockchain network 450 of an SSI infrastructure, which provides a blockchain 400. The blockchain 400 is, for example, a public, permissioned blockchain managed by the blockchain network 450 as a distributed ledger. The blockchain network 450 comprises a plurality of blockchain servers 412, 432, each of which stores, for example, a copy of the blockchain 400 in a corresponding memory 418, 438. The blockchain servers 412, 432 each comprise a processor 414, 434 for executing program instructions 416, 436 of programs 419, 439 for managing the blockchain 400. Finally, the blockchain servers 412, 432 each comprise a communication interface 420, 440 for communicating via the network 103, for example with the issuer computer system 100 and / or the requesting computer system 150 of the entity.

[0130] An entity for which a digital credential with entity-related attributes is issued can, for example, also be an entity managing the register provided by the register computer system 250, such as a competent court at a commercial register, or an entity providing the issuing service of the issuing computer system 100, such as a corresponding company. In principle, corresponding digital credentials with entity-related attributes can be issued for all entities participating in the system. If an additional entity wishes to participate in the implemented system for the first time or join the implemented system, the corresponding entity must request that the issuing computer system 100 issue a corresponding digital credential with entity-related attributes, as described above for an exemplary entity using the computer system 150.

[0131] Figure 9shows an exemplary method for requesting a digital credential for an entity by a computer system of the entity. In block 70, the computer system creates a corresponding issuance request for issuing the digital credential. The issuance request includes a register ID assigned to the requesting entity, which identifies a register entry of the entity in a registry, a domain assigned to the requesting entity, an email address of an official representative of the entity, and a decentralized identifier (DID) of the entity. In block 72, the computer system sends the issuance request over a network to an issuer computer system. In block 74, the computer system receives the digital credential over the network from the issuer computer system in response to the sent issuance request.For example, the method further comprises an optional challenge-response procedure for proving control of the computer system over a domain of the entity as a prerequisite for block 74. During the challenge-response procedure, the computer system receives a random value as a challenge from the issuing computer system, which the computer system publishes in the domain of the entity as a response to receiving the challenge.

[0132] Figure 10 shows an exemplary method for authentication using a digital credential by a computer system of an entity. In block 80, the computer system receives an authentication request from a computer system authenticating the entity. In block 82, in response to the authentication request, the computer system of the entity sends the digital credential of the entity to the computer system authenticating the entity.

[0133] Figure 11shows an exemplary method for authentication using a digital credential. In block 90, an authenticating computer system sends an authentication request to a computer system authenticating an entity. In block 92, the authenticating computer system receives the corresponding digital credential of the entity to be authenticated in response to the authentication request. In block 94, the authenticating computer system authenticates the entity to be authenticated using the digital credential. List of reference symbols

[0134] 100 Issuer computer system 101 System 103 Network 102 Issuer program 104 Utility 110 Digital credential 112 Memory 114 Programs 118 Public cryptographic key 120 Protected memory area 124 Private cryptographic key 124 Processor 126 Program instructions 128 Communications interface 150 Requesting computer system 156 Browser 152 Memory 154 Programs 156 Processor 158 Program instructions 162 Communications interface 164 User interface 200 Representative computer system 201 Official representative 202 ID wallet 204 Protected memory area 206 Email client 208 Client program 212 Memory 214 Programs 216 Processor 218 Program instructions 222 Communications interface 224User interface 250Register computer system 252Memory 254Register entries 256Processor 258Program instructions 262Communication interface 300Domain server 302Memory 304Domain 306Processor 308Program instructions 312Communication interface 400Blockchain402 Authentication data 404 Public cryptographic keys 406 Data schemas 408 Revocation data 412 Blockchain server 414 Memory 416 Processor 418 Program instructions 419 Programs 420 Communication interface 432 Blockchain server 434 Memory 436 Processor 438 Program instructions 439 Programs 440 Communication interface 450 Blockchain network 500 ID provider computer system 502 ID token 600 Issuance request 602 Email 602 Machine-readable optical code 700 Audit computer system

Claims

1. A method for issuing a digital credential (110) for an entity by an issuer computer system (100), wherein the method comprises: • receiving an issuing request (600) for issuing the digital credential (110) via a network (103) from a requesting computer system (150), wherein the issuing request (600) comprises a domain (304) associated with the requesting entity, an email address of an official representative of the entity and a decentralized identifier, • sending a registry query for a registry entry (254) as proof of the existence of the entity via the network (103) to a registry computer system (250), • in response to sending the registry query, receiving a digital registry extract of the entity as proof of existence via the network (103) from the registry computer system (250), • checking a link between the domain (304) and the decentralized identifier, • sending an email (602) with an invitation to establish an encrypted communication channel to the email address, • in response to sending the email (602), establishing an encrypted communication channel between the issuer computer system (100) and an ID wallet (202) of the official representative of the entity via the network (103), • sending a request for a digital ID credential of the official representative of the entity with personal attributes of the representative via the encrypted communication channel, • in response to sending the request, receiving the digital ID credential via the encrypted communication channel, • verifying the authenticity of the digital ID credential, • checking the representation authorization of the official representative of the entity using the personal attributes of the digital ID credential and the digital registry extract of the entity, • on successful verification of the representation authorization, issuing the digital credential (110) with entity-related attributes using the digital registry extract, • sending the digital credential (110) in response to the received issuing request (600) via the network (103) to the requesting computer system (150).

2. The method according to claim 1, wherein the issuing request (600) comprises a registry ID of the entity, wherein the registry query comprises the registry ID.

3. The method according to any one of the preceding claims, wherein the registry query comprises a search query for entries of the entity.

4. The method according to any one of the preceding claims, wherein a plurality of registry queries are sent via the network (103) to a plurality of registry computer systems (250).

5. The method according to claim 4, wherein in response to sending the registry query, a plurality of digital registry extracts of the entity are received via the network (103) from the plurality of registry computer systems (250), wherein the digital credential (110) with the entity-related attributes is issued using the plurality of digital registry extracts.

6. The method according to any one of the preceding claims, wherein checking the link between the domain (304) and the decentralized identifier comprises checking whether a reference to the decentralized identifier is stored under the domain (304).

7. The method according to any one of the preceding claims, wherein checking the link between the domain (304) and the decentralized identifier comprises retrieving a decentralized identifier document of the decentralized identifier and checking whether the decentralized identifier document comprises a reference to the domain (304).

8. The method according to any one of the preceding claims, wherein the method further comprises checking a control of the requesting computer system (150) via the domain (304).

9. The method according to claim 8, wherein the checking of the control is performed using a challenge-response method, wherein the issuer computer system (100) sends a challenge to publish in the domain (304) via the network (103) to the requesting computer system (150), wherein the issuer computer system (100) checks the response in the form of the publication in the domain (304).

10. The method according to any one of the preceding claims, wherein the email (602) comprises the invitation to establish the encrypted communication channel in the form of a machine-readable optical code (602).

11. The method according to any one of the preceding claims, wherein the encrypted communication channel is a DIDComm channel and / or wherein the issuer computer system (100) is a computer system of an issuer service of an SSI infrastructure.

12. The method according to any one of the preceding claims, wherein the method further comprises using the digital credential (110) by the requesting computer system (150), wherein the use comprises sending the digital credential (110) to an authenticating computer system in the course of authenticating the entity to the authenticating computer system.

13. An issuer computer system (100) for issuing a digital credential (110) for an entity, wherein the issuer computer system (100) comprises a first processor (124), a first memory (112) having first program instructions (114) and a first communication interface (128) for communication via a network (103), wherein execution of the first program instructions (114) by the first processor (124) of the issuer computer system (100) causes the first processor (124) to control the issuer computer system (100) for: • receiving an issuing request (600) for issuing the digital credential (110) via a network (103) from a requesting computer system (150), wherein the issuing request (600) comprises a domain (304) associated with the requesting entity, an email address of an official representative of the entity and a decentralized identifier, • sending a registry query for a registry entry (254) as proof of existence of the entity via the network (103) to a registry computer system (250), • receiving a digital registry extract of the entity as proof of existence via the network (103) from the registry computer system (250), • checking a link between the domain (304) and the decentralized identifier, • sending an email (602) with a request to establish an encrypted communication channel to the email address, • in response to sending the email (602), establishing an encrypted communication channel between the issuer computer system (100) and an ID wallet (202) of the official representative of the entity via the network (103), • sending a request for a digital ID credential of the official representative of the entity with personal attributes of the representative via the encrypted communication channel, • in response to sending the request, receiving the digital ID credential via the encrypted communication channel, • verifying the authenticity of the digital ID credential, • checking the representation authorization of the official representative of the entity using the personal attributes of the digital ID credential and the digital registry extract of the entity, • on successful verification of the representation authorization, issuing the digital credential (110) with entity-related attributes using the digital registry extract, • sending the digital credential (110) in response to the received issuing request (600) via the network (103) to the requesting computer system (150).

14. A system (101) comprising an issuer computer system (100) according to claim 13 and a requesting computer system (150), wherein the requesting computer system (150) comprises a second processor (156), a second memory (152) with second program instructions (154) and a second communication interface (162) for communication via the network (103), wherein executing the second program instructions (154) by the second processor (156) of the requesting computer system (150) causes the second processor (156) to control the requesting computer system (150) for: • creating the issuing request (600) to issue the digital credential (110), • sending the issuing request (600) via the network (103) to the issuer computer system (100), • in response to the sent issuing request (600), receiving the digital credential (110) via the network (103) from the issuer computer system (100).

15. The system (101) according to claim 14, wherein the execution of the second program instructions (154) by the second processor (156) of the requesting computer system (150) further causes the second processor (156) to cause the requesting computer system (150) to use the received digital credential (110), wherein the use comprises sending the digital credential (110) to an authenticating computer system in the course of authenticating the entity to the authenticating computer system.