A sovereign identity object and methods for its generation and verification

Abstract

This invention relates to the field of digital identity and information security technology, specifically providing a sovereign identity object and its generation and verification method. The sovereign identity object includes: an identity identifier, containing a cryptographically verifiable identity representation of a digital entity or a reference thereof; a category declaration, containing an information index declaring the category to which the digital entity belongs in an externally configurable category rule base; a responsibility anchoring, containing an immutable reference pointing to a controller entity; and a service permission, containing an authorization digest and authorization index of the digital entity. Through this scheme, a technically native projection of the control and responsibility relationship is achieved, immutably binding the responsible subject to the digital entity at the decentralized identity level, providing cryptographic primitives for behavior tracing and accountability.

Description

Technical Field

[0001] This invention relates to the field of digital identity and information security technology, specifically providing a sovereign identity object and its generation and verification method. Background Technology

[0002] Currently, the digital environment is undergoing a fundamental evolution, shifting from primarily serving as a reflection of human activities to becoming a stage for autonomous interaction and collaboration among digitally native entities (such as AI agents, IoT devices, and automated organizations). This transformation presents fundamental challenges to existing digital identity technologies.

[0003] The core design philosophy of existing mainstream paradigms, such as X.509 PKI and OAuth 2.0, is to "map the identity of real-world subjects to the digital space." However, this paradigm reveals fundamental limitations when dealing with purely digitally native entities: First, there is a lack of inherent identity models. The existing system cannot define and verify the individual "legal personhood" or accountable identity of entities such as AI agents, nor can it technically express the continuous control and responsibility relationship between them and their creators and controllers.

[0004] Second, there is the efficiency bottleneck of the interaction paradigm. Existing technologies separate identity authentication, attribute declaration, and permission granting into multiple sequential steps, relying on centralized institutions or complex chain queries, which contradicts the high-frequency, real-time, and automated trust-building interaction requirements between digital entities.

[0005] Third, the rigidity of identity semantics. The digital world comprises diverse subspaces with varying rules, including the global internet, industry alliances, and private networks. The semantics of existing identity technologies are usually fixed or centrally defined, lacking a mechanism that allows an identity to dynamically and verifiably declare its specific category and rights under the rules of different environments.

[0006] In recent years, next-generation identity schemes, represented by the W3C Decentralized Identifier (DID), have emerged. DID allows entities to generate and control their own identifiers without relying on a centralized registry, thus addressing to some extent the dependence of traditional PKI systems on centralized certificate authorities. However, the DID scheme still has significant shortcomings in addressing the core technical problem that this invention aims to solve: First, DID documents primarily define public key verification methods, lacking native semantic fields expressing "attribution of responsibility." In scenarios lacking intermediary guarantees, the verifier cannot determine the controller or responsible party of the digital entity solely based on the DID document, nor can it trace potential chains of responsibility. This "lack of governance semantics" makes DID solutions difficult to directly apply to commercial scenarios requiring compliance and accountability.

[0007] Secondly, the DID document structure is fixed and lacks the ability to express hierarchical interactive permissions. In the existing DID system, authentication, permission discovery, and service invocation must be completed through out-of-band protocol negotiation, which cannot achieve the atomic operation of "authentication equals interaction" and makes it difficult to meet the high-frequency, real-time trust-building interaction needs between digital entities.

[0008] Finally, the DID document does not contain a category index pointing to an external configurable rule base, which makes it impossible for the same identity to dynamically declare its category and behavioral capability boundaries in different industry rule bases or legal contexts. The identity semantics are rigid, which hinders cross-domain trusted collaboration.

[0009] In conclusion, neither traditional centralized identity systems nor existing decentralized identity solutions have fundamentally solved the technical challenges faced by digital native entities in establishing identity sovereignty, anchoring responsibility relationships, expressing dynamic semantics, and enabling autonomous interaction. The industry urgently needs a fundamental identity primitive native to the digital world. This primitive should function as a self-contained unit, atomically carrying and proving a digital entity's identity, its undeniable responsibility relationship with its controller, and its hierarchical interaction permissions. Summary of the Invention

[0010] To overcome the above-mentioned deficiencies, this invention is proposed to address the technical problem of lacking a self-contained, atomically verifiable mechanism to fully, clearly, and immutably project the relationship of "control" and "responsibility" in the real world onto digital identity objects when digital entities participate in interactions as independent nodes, and to make it the inherent basis for all subsequent authorization and interaction verification.

[0011] In a first aspect, the present invention provides a sovereign identity object, comprising the following information items: An identity identifier contains a cryptographically verifiable representation of a digital entity or a reference thereof; The category declaration item contains an index of information used to declare the category to which the digital entity belongs in an externally configurable category rule base; Responsibility anchors contain immutable references to a controller entity; Service permission items include the authorization summary and authorization index of the digital entity; The authorization digest is a piece of cryptographic data that can be directly verified, containing basic interaction permissions and the corresponding basic service endpoint identifier; The authorization index includes a resource identifier for locating a complete authorization statement, which includes an extended permission policy, a transaction rule package index, and a corresponding complex transaction service endpoint identifier.

[0012] Furthermore, the sovereign identity object is a machine-readable digital object, which is digitally signed by the controller entity through an immutable reference, and the controller assumes control responsibility.

[0013] Furthermore, the externally configurable category rule base supports the definition and versioning management of multiple classification systems.

[0014] Furthermore, the authorization index includes any one of the following: a cryptographic hash value, an identifier conforming to a naming resolution protocol, or a smart contract address.

[0015] Furthermore, the digital object undergoes normalization of its structured data to ensure the determinism and verifiability of the digital signature.

[0016] Secondly, the present invention provides a method for generating a sovereign identity object, comprising the following steps: A1: Determine the category that the digital entity needs to declare from an external configurable category rule base, obtain the identifier from the selected identifier resolution service and configure it to point to the category; A2: Construct a structured data, which includes at least: the identity identifier, the category declaration, the responsibility anchor, and the service permission. A3: Digitally sign the structured data using an immutable reference to the controller entity; A4: Output the signed structured data as the sovereign identity object.

[0017] Furthermore, when constructing structured data in step A2, the step of normalizing the structured data is also included. The normalization process includes removing invalid spaces and sorting the key names lexicographically.

[0018] Thirdly, the present invention provides a method for verifying a sovereign identity object, comprising the following steps: B1: Verify the validity of the digital signature; B2: After the signature verification is successful, parse the service permission items; B3: Execute basic interactions and / or deep transactions based on the parsing results; The basic interaction initiated by the basic service endpoint identifier is verified and parsed based on the authorization digest. The complete authorization statement is obtained based on the authorization index, and deep trading is guided according to the extended permission policy in the statement and the complex transaction server endpoint identifier.

[0019] Furthermore, the basic interaction includes an identity exchange operation, and the deep transaction includes a deterministic computation process performed in a specified execution environment according to the transaction rule package.

[0020] The working principle and beneficial effects of this invention: In implementing the technical solution of this invention, a machine-readable digital data structure called "Sovereign Identity Object (SIO)" is constructed to atomically bind the identity identifier, category declaration, responsibility anchor, and service permission items of a digital entity into a whole through the controller's digital signature. During generation, the controller selects a category identifier from an externally configurable category rule base, constructs structured data, performs normalization processing, signs it with a private key, and finally outputs the SIO. During verification, the other party verifies the signature validity and parses the service permission items: either directly initiating immediate interaction using the basic endpoint in the authorization digest, or obtaining the complete rule declaration package through the authorization index to guide deep transactions.

[0021] It achieves a technologically native projection of the relationship between control and responsibility, and for the first time, it immutably binds the responsible subject to a digital entity at the decentralized identity level, providing cryptographic primitives for behavior tracing and accountability. Through the atomic design of "verification is interaction", it compresses identity authentication, responsibility confirmation and permission discovery into a single operation, greatly improving the efficiency of establishing trust between machines. Through an externally configurable category rule base and hierarchical service permission items, it supports the flexible adaptation of identity semantics in diverse environments and provides an extensible rule guidance mechanism for complex transactions. Detailed Implementation

[0022] Some embodiments of the present invention are described below. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0023] Example 1 This embodiment proposes a sovereign identity object, which is a machine-readable digital object containing the following information items bound together by a digital signature to form a uniformly verifiable whole.

[0024] Identity identifier: It contains at least a cryptographically verifiable identity representation of a digital entity or a reference thereof, wherein the verifiable identity representation refers to a public key, blockchain address, and DID, etc., and the reference is a pointer to them, such as a digital object identifier (handle). In this embodiment, the cryptographic public key of the entity is used directly.

[0025] Category Declaration: Contains an index of information used to declare the category to which the digital entity belongs in an externally configurable category rule base. This rule base exists independently and is designed to define, index, and maintain one or more digital entity classification systems (such as legal: subject-agent-object, industry, professional classifications, etc.) and their relationship rules.

[0026] Responsibility Anchor: Contains an immutable reference to the controller entity that digitally signs the sovereign identity object and assumes control responsibility, used to realize the technical projection of control relationships.

[0027] Service permission items: contain the authorization summary and authorization index of the digital entity.

[0028] (i) Authorization digest: A piece of cryptographic data that can be directly verified, containing at least one basic interaction permission (such as preferred_operation: exchangeIdentity under interaction_meta) and the corresponding basic service endpoint identifier.

[0029] (ii) Authorization Index: A resource identifier (such as a hash value, resolution identifier, smart contract address, etc.) used to locate and obtain a complete authorization statement, which includes an extended permission policy, a transaction rule package index and a corresponding complex transaction service endpoint identifier, wherein the transaction rule package is hosted, loaded and guided for execution on the complex transaction service endpoint.

[0030] In one implementation, the sovereign identity object is defined using a structured data format (such as JSON), with a global structure as shown below, ensuring that identity, category, responsibility, and authority are atomically bound at the technical level.

[0031] JSON { "identity_identifier": { "public_key": "jwk: / / example / subject / pk_id_12345", "key_algorithm": "EdDSA }, "category_declaration": { "classification_index": "urn:oid:law:entity:ABC:ProfessionalService" }, "responsibility_anchor": { "controller_reference": "sha256(jwk: / / example / ctrl / pk_id_9876)" / This acts as the immutable citation (the hash of thecontroller's public key) / }, "service_permissions": { "auth_summary": { "base_service_endpoint_id": "https: / / api.domain.com / v1 / profile", "basic_permissions": [ { "preferred_operation": "readIdentityPayload", "scope": "core_attributes" } ] }, "auth_index": { "resource_identifier": "sha256:fullpolicyhash_abcdefg1234567890", "policy_type": "AdvancedAccessControlPolicy" } }, "proof": { "signature": "SIG_OF_CONTROLLER", "algorithm": "EdDSA"}}

[0032] Example 2

[0033] This embodiment proposes a method for generating a sovereign identity object, which specifically includes the following steps A1-A4.

[0034] Step A1: The controller first determines the category identifier that the digital entity needs to declare from an externally configurable category rule base. This rule base can be a set of rules defined by national standards or industry standards, or any set of rules that are customized by relevant parties and are publicly queryable and parsable, including ontology models, data rules, metadata dictionaries, etc.

[0035] For example, for a data analysis model entity, the controller selects "AccreditedDataProcessor" as its category from a data service industry certification alliance rule base, records the namespace and version information of the rule base, and obtains and configures a digital object identifier for it to form a complete category declaration.

[0036] Step A2: The controller constructs a structured data set in JSON-LD format, containing the following information items: Identity Item: Contains a cryptographically verifiable identity representation of the digital entity, which in this embodiment is the digital entity's public key. This identity representation serves as the unique cryptographic basis for the digital entity's identity and is used for subsequent signature verification and authentication. In this embodiment, the identity item also includes a resolvable globally unique identifier (e.g., handle: 10.123.456 / ABC789) that binds the digital entity's public key and other relevant data.

[0037] Category declaration: Contains the selected category identifier and a reference to the configurable category rule base.

[0038] Responsibility anchor: Contains an immutable reference to the controller entity. In this embodiment, the hash value of the controller's public key is used as the reference.

[0039] Service permission item: includes authorization digest and authorization index. The authorization digest is cryptographic data containing at least one basic interaction permission and the corresponding basic service endpoint identifier. The authorization index is a resource identifier used to locate the complete authorization statement.

[0040] To ensure the determinism and verifiability of digital signatures, the structured data must be normalized before the controller signs with the private key. This embodiment uses the JCS (JSON Canonicalization Scheme) algorithm. This normalization process removes invalid spaces, sorts the keys lexicographically, and encodes the data in a deterministic manner, ensuring that the hash value calculated by the verifier is completely consistent with the hash value used for signing after the data is transmitted between different systems.

[0041] Step A3: Use the controller entity's private key (in this embodiment, the EdDSA algorithm is used) to digitally sign the normalized structured data and fill the signature value into the signature_value field of the proof field.

[0042] Step A4: Output signed structured data as the final sovereign identity object, which can be hosted in any accessible storage location (such as IPFS, a web server, or user-owned storage space) for other digital entities to discover and verify.

[0043] It should be noted that although the steps in the above embodiments are described in a specific order, those skilled in the art will understand that in order to achieve the effects of the present invention, different steps do not necessarily have to be executed in such an order. They can be executed simultaneously (in parallel) or in other orders, and these variations are all within the scope of protection of the present invention.

[0044] Example 3 This embodiment proposes a method for verifying a sovereign identity object, specifically including the following steps B1-B3.

[0045] Step B1: The verifier (e.g., the data partner) obtains the SIO (Sovereign Identity Object) of the target digital entity (e.g., the data analysis model), parses its JSON-LD structure, and extracts each information item. The signature value in the proof is verified using the cryptographic public key of the identity item in the SIO (or the controller's cryptographic public key obtained through the responsibility anchor item).

[0046] Specifically, the verifier first performs the same normalization process (JCS algorithm) on all data in the SIO (Sovereign Identity Object) except for the proof field, and then uses the public key to verify whether the signature value matches the normalized data. If the signature verification passes, the integrity and authenticity of the SIO are proven; if the verification fails, the interaction is rejected.

[0047] Step B2: After the signature verification is successful, the verifier parses the service_permissions field and processes the authorization summary (authorization_summary) and authorization index (authorization_index) respectively.

[0048] Step B3: Perform basic interactions and / or deep transactions based on the parsing results.

[0049] Basic Interaction (Based on Authorization Digest) The verifier reads the `base_endpoints` field from the `authorization_summary` to obtain the basic service endpoint identifier (e.g., `https: / / model.example.com / api / v1 / describe`). Simultaneously, it reads the `preferred_operation` field from the `interaction_meta` to determine the basic interaction operation type (e.g., `query_metadata`).

[0050] The authenticator then sends a request to the underlying service endpoint, such as an HTTP GET request to query model metadata. This process compresses authentication, accountability, and permission discovery into a single atomic operation, achieving an efficient "authentication as interaction" paradigm.

[0051] In one implementation, when a digital entity wishes to establish a basic interaction with another digital entity, the initiator first constructs a basic interaction request object. This object corresponds to the implementation of the "authorization digest" in SIO (Sovereign Identity Object) and is used to initiate the interaction of the basic endpoint. Its permission verification is directly anchored to the responsible entity in the identity object.

[0052] This basic interaction request object contains the following information items: Identifier: Contains a globally unique logical index reference for both the initiator and receiver. This reference has a self-describing name resolution protocol type (rather than being limited to a specific protocol), supporting interoperability across resolution systems.

[0053] Operational semantics: Contains at least one basic interaction action (such as exchangeIdentity) and its corresponding underlying service endpoint identifier, which is extracted directly from the base_endpoints field of the authorization_summary field in SIO.

[0054] Environment attribute: Contains a type declaration of the initiator's Secure Execution Environment (SEE), which demonstrates the controlled nature of the action. The SEE type may include a trusted execution environment, a secure container, or a distributed multi-party computation system, etc.

[0055] Verification Item: Contains a digital signature generated by the initiator's private key. Authorization of this signature requires verification by SEE to confirm its compliance with the controller's initial signing policy.

[0056] The abstract schema example for basic interactions is as follows: { "request_type": "basic_interaction", "identifiers": { "sender": { "id": "STRING", "scheme": "PROTOCOL_REF"}, "target": { "id": "STRING", "scheme": "PROTOCOL_REF"} }, "operation_spec": { "verb": "exchangeIdentity", "endpoint_id": "URI_OR_IDENTIFIER" }, "proof_context": { "see_type": "ISOLATED_ENV_REF", "signature": "CRYPTOGRAPHIC_VALUE" } } Deep trading (based on authorized indexes) When the verifier needs to perform more complex operations (such as submitting sensitive data for analysis and calculation), it reads the resource_pointer in authorization_index to obtain the resource identifier (such as the Handle identifier handle_id_for_data_policy_package).

[0057] Based on the resource identifier, a complete authorization statement is obtained through the appropriate resolution protocol (such as the Handle protocol). This statement contains extended permission policies and rule statement packages. The rule statement package is used to bind roles, atomic operations, and constraints for multi-party collaboration.

[0058] Parse the rule declaration package to obtain the complex transaction server endpoint identifier (such as the secure enclave server endpoint https: / / tee.example.com / compute) and the execution grid formation protocol. Based on this protocol, the verifier prepares to join or instantiate an execution grid for deep trading (i.e., the "specified execution environment" and "deterministic computation process" described in the third aspect of the "Summary of the Invention").

[0059] Following the instructions in the rules package, the verifier encrypts the sensitive data and sends it to the designated complex transaction service endpoint, thus initiating the deterministic computation workflow.

[0060] In one implementation, when a digital entity needs to conduct a deep transaction, the initiator extracts a resource identifier from the authorization_index field of the SIO (Sovereign Identity Object) and uses this identifier to obtain a deep transaction bootstrapping object. This object corresponds to the implementation of the "authorization index" in the SIO and is used to guide the entity into a private execution environment. The specific governance roles are pre-defined in the rule package template.

[0061] This deep trading bootstrapping object contains the following information items: Resource index item: Contains a resource identifier (such as a hash value, a name resolution protocol-compliant identifier, or a smart contract address) pointing to the rule declaration package, and includes a version label to ensure consistency of governance logic. This rule declaration package defines the roles, atomic operations, and constraints of multi-party collaboration.

[0062] Environment configuration hints: Contain technical hints about the underlying foundation (such as a licensed ledger, a trusted execution environment network, or a zero-knowledge proof system) to guide the instantiation of the execution mesh.

[0063] Responsibility bindings: These contain references to responsibility anchors in SIO, which the Secure Execution Environment (SEE) uses to verify whether the signer of the relevant policy in the rule statement package has legitimate control.

[0064] Execution trigger: Contains a grid instantiation instruction signed by the initiator, used to trigger deterministic execution logic between the discovery grid and the execution layer.

[0065] The abstract schema example for deep trading is as follows: { "request_type": "contract_initiation", "contract_reference": { "package_id": { "id": "STRING", "scheme": "PROTOCOL_REF"}, "integrity_check": "HASH_VALUE" }, "execution_hint": { "substrate_type": "TECH_SPEC_ID", "formation_protocol": "PROTOCOL_REF" }, "governance_binding": { "anchor_ref": "CONTROLLER_ID", "proof": "CRYPTOGRAPHIC_SIGNATURE" } } In one implementation, the transaction initiator (seller) configures and signs a transaction rules statement package and publishes its summary (including an index) as a digital object (e.g., a digital object with the content and nature of "transaction offer"), binding the execution logic to the identity and role of the transaction participants. The rules statement package contains the following elements: Execution grid (environment and system) formation protocol: Defines the protocol references for instantiating execution grids, such as the path to join a seller's permanent execution grid (e.g., a distributed or centralized business system operated by the seller); Role Definition: The business system defines various roles involved in the transaction (such as buyer, seller, bank, logistics, buyer's lawyer, seller's lawyer as evidence / audit node), as well as the permissions and responsibilities of each role; Atomic operation: The system defines the smallest executable unit of operation (such as balance verification, fund payment, delivery, and receipt executed by smart contracts). Triggering behavior: The system defines the business conditions and rules for triggering operations (such as "the contract takes effect when the notification of successful fund freezing is issued" or "the goods are shipped after the first payment is received"). Identity anchoring: The rule statement package index and the verifiable, immutable references to the publisher and its controller are bound together within a digital structure representing an identity, and are signed by the controller with its verifiable, immutable references to the identity.

[0066] It should be noted that although the steps in the above embodiments are described in a specific order, those skilled in the art will understand that in order to achieve the effects of the present invention, different steps do not necessarily have to be executed in such an order. They can be executed simultaneously (in parallel) or in other orders, and these variations are all within the scope of protection of the present invention.

[0067] Example 4 This embodiment proposes an application in a data collaboration scenario, in which a research institution (the controller) creates a sovereign identity object for its trained data analysis model.

[0068] 1. Object content: Identity identifier: The public key of the model container.

[0069] Category declaration: Refers to the AccreditedDataProcessor category in the Alliance Rule Base.

[0070] Responsibility anchor: The hash of the research institution's own sovereign identity object.

[0071] Service permission items: Service summary: A hash of {"perm": "query_metadata", "endpoint": "https: / / model.example.com / api / v1 / describe"}. Allows querying model metadata.

[0072] Service Index: A Handle identifier that points to detailed data usage policies and rules packages.

[0073] Signature: The research institution signed the above data content using the private key of its own sovereign identity object.

[0074] 2. Collaboration Process Basic interaction: The data partner verifies the object signature, confirms that the model is an authentication processor responsible for a certain organization, and directly obtains the metadata query endpoint from the digest for test calls (taking this as an example).

[0075] Deep Computing: When a partner needs to submit sensitive data for computation, a complete policy statement is retrieved based on the authorization index. This statement includes various usage conditions and terms, as well as contractual mechanisms, including but not limited to provisions such as: "Raw data must be encrypted and sent to the secure enclave server endpoint https: / / tee.example.com / compute. Only specified analytical functions can be executed, and results are returned after differential privacy processing." The partner is then securely guided by the contractual mechanism to this dedicated endpoint to initiate the computation workflow according to the statement.

[0076] This process demonstrates how a single controller can maintain a clear chain of responsibility and governance in complex collaborations by generating proprietary identity objects.

[0077] The sovereign identity object and method provided by this invention have the following beneficial effects: First, it achieves a technologically native projection of responsibility relationships: through the mandatory binding of "responsibility anchors" with digital signatures, it is the first time, at the decentralized identity level based on cryptography, that the control and responsibility relationships of human / institutional controllers over digital entities have been technically fixed in an immutable manner, providing cryptographic primitives for behavioral traceability and accountability in the digital world. Simultaneously, the establishment of the controller anchoring mechanism is not merely a declaration about the controller within the identity object. While ensuring the decentralization of autonomous entity identities, it enables controllers to achieve fine-grained control over the private keys of relevant entities, laying the foundation for digital governance through dual control linking identity and behavior.

[0078] Second, it lays the technological foundation for a machine-autonomous world governance mechanism: the aforementioned design enables human controllers to act as clear sources of responsibility and rule definers. By generating identity objects carrying category declarations (through mapping and parsing various configurable rule bases), they can customize "behavioral capability" declarations for their agents in different digital environments, generating compliant proprietary identities for the same entity in different digital environments. This provides a unified and scalable identity and permission carrier for complex collaborations requiring fine-grained management of rights and responsibilities, such as the flow of data elements, thereby ensuring verifiable governance capabilities for the autonomous digital ecosystem at the technological level.

[0079] Third, it achieves a highly efficient and automated "verification as interaction" paradigm: the "authorization digest" embedded in the object's "service permission item" contains directly usable basic endpoints, compressing multiple steps of identity and responsibility verification and permission discovery into a single atomic operation, greatly improving the efficiency of establishing trusted connections between machines. The "complete permission index" includes the discovery of preset transaction rule packages, which can directly guide entities to conduct deep and complex transactions anchored by hierarchical identities and controllers. Both the authorization digest and transaction rule packages can be integrated with external indexing services and published or discovered in public or other environments.

[0080] Fourth, it provides flexible, customizable primitives that support diverse transaction rules: Pre-defined transaction rules are hosted and loaded at complex transaction server endpoints via "service permission items," enabling autonomous entities to align transaction rules and environments (i.e., transaction rule packages) while mutually verifying their identities. This also opens up a market for customizable, pluggable transaction rule packages for the network transaction ecosystem between digital entities, which can be seen as an evolution of the existing application ecosystem in a platform-free, decentralized, self-interacting proxy network.

[0081] The following is a supplementary explanation of the terminology used in this invention: Sovereign Identity Object (SIO): A machine-readable digital data structure that atomically binds identity identifiers, category declarations, responsibility anchors, and service permission items into a whole through digital signatures, serving as the basic identity primitive of a digital entity.

[0082] Identity Item: A component of SIO, containing a cryptographically verifiable identity representation of a digital entity and a globally unique logical reference identifier used to uniquely identify the entity.

[0083] Category Declaration Item: A component of SIO, containing an index to an externally configurable category rule base, used to declare the category to which a digital entity belongs in a specific classification system (such as "AI Agent" or "Certification Data Processor").

[0084] Responsibility Anchor: A component of SIO, containing immutable references to the controller entity (such as controller public key hashes) used to technically project the control and responsibility relationship.

[0085] Service Permission Items: A component of SIO, containing a permission digest and permission index, used to declare the behavioral capabilities and interaction permissions of digital entities.

[0086] Authorization Summary: Part of the service permission items, it is a piece of cryptographic data that can be directly verified, containing basic interaction permissions and corresponding basic service endpoint identifiers, supporting instant communication of "verification is interaction".

[0087] Authorization Index: A part of the service permission item, it is a resource identifier (such as URL, Handle, hash value, public key, and smart contract address) used to identify, locate, and reference the complete authorization statement, extended permission policy, or transaction rule package.

[0088] External configurable category rule base: A set of rules that exists independently of SIO, defining and maintaining the classification system of digital entities (such as national standards, industry standards, ontology models, etc.), and supporting version management and dynamic referencing.

[0089] Controller entity: The entity (such as a human or organization) that assumes control and responsibility for the digital entity, signs the SIO with its PKI private key, and is referenced in the responsibility anchor.

[0090] Canonicalization: The process of standardizing structured data before digital signature (such as the JCS algorithm). By removing invalid spaces, sorting key names, and other operations, it ensures the determinism of signature verification between different systems.

[0091] Basic Interaction Request Object: The request object corresponding to the "Authorization Summary" implementation, which includes identification items, operation semantic items, environment attribute items and verification items, and is used to initiate the interaction of the basic endpoint.

[0092] Deep Transaction Guidance Object: The object corresponding to the "Authorization Index" implementation, including resource index items, environment configuration prompt items, responsibility binding items, and execution trigger items, used to guide entities into the private execution environment.

[0093] Secure Execution Environment (SEE): Provides a strongly isolated execution environment at the hardware or software level (such as TEE, secure container, MPC system) to ensure that private keys cannot be extracted throughout their entire lifecycle and that policy logic cannot be bypassed.

[0094] Digital objects: generally refer to digital resources, entities, and behaviors that exist in the digital space and can be identified, abstracted, objectified, or otherwise defined.

[0095] Rule declaration package: A digital object containing role definitions, atomic operations, constraints, and execution mesh forming protocol references, bound to the verifiable identities of the two parties in the transaction, serving as a "contract template" for multi-party coordination.

[0096] Execution layer: Provides a private execution environment, which is an execution grid indexed according to rule declaration packages or an execution grid instantiated on a specified underlying base.

[0097] Execution grid: A private, deterministic execution environment instantiated on a specified underlying base according to the rule declaration package. It can be permanent (pre-set business system) or temporary (destroyed after the transaction is completed).

[0098] Substrate: The underlying technology platform on which the execution grid depends, including distributed ledgers (such as Hyperledger Fabric), Trusted Execution Environment (TEE) networks, zero-knowledge proof (ZK) execution systems, etc.

[0099] Role Definition: A component of the rules statement package, defining the various roles involved in the transaction (such as buyer, seller, bank, logistics, lawyer, auditor) and their authority and responsibilities.

[0100] Atomic operation: The smallest executable unit of operation (such as fund verification, payment execution, and delivery confirmation) defined in the rule declaration package, which is triggered or executed by a specific role.

[0101] Mesh Formation Protocol: The protocol specification referenced in the rule declaration package defines the specific steps and technical requirements for instantiating and executing the mesh based on the contents of the rule package.

[0102] Evidence / Audit Node: A special node (such as a lawyer node) embedded in the execution grid, configured to record intermediate events and final results within the execution grid to a persistent archive, forming auditable records.

[0103] The technical solutions of the present invention have now been described. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions resulting from these changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. A sovereign identity object, characterized in that, Includes the following information items: An identity identifier contains a cryptographically verifiable representation of a digital entity or a reference thereof; The category declaration item contains an index of information used to declare the category to which the digital entity belongs in an externally configurable category rule base; Responsibility anchors contain immutable references to a controller entity; Service permission items include the authorization summary and authorization index of the digital entity; The authorization digest is a piece of cryptographic data that can be directly verified, containing basic interaction permissions and the corresponding basic service endpoint identifier; The authorization index includes a resource identifier for locating a complete authorization statement, which includes an extended permission policy, a transaction rule package index, and a corresponding complex transaction service endpoint identifier.

2. The sovereign identity object according to claim 1, characterized in that, The sovereign identity object is a machine-readable digital object, which is digitally signed by the controller entity through an immutable reference, and the controller assumes control responsibility.

3. A sovereign identity object according to claim 1, characterized in that, The externally configurable category rule base supports the definition and versioning management of multiple classification systems.

4. A sovereign identity object according to claim 1, characterized in that, The authorization index includes any one of the following: a cryptographic hash value, an identifier conforming to a naming resolution protocol, or a smart contract address.

5. A sovereign identity object according to claim 2, characterized in that, The digital object performs normalization processing on its structured data to ensure the determinism and verifiability of the digital signature.

6. A method for generating a sovereign identity object as described in any one of claims 1 to 5, characterized in that, Includes the following steps, A1: Determine the category that the digital entity needs to declare from an external configurable category rule base, obtain the identifier from the selected identifier resolution service and configure it to point to the category; A2: Construct a structured data, which includes at least: the identity identifier, the category declaration, the responsibility anchor, and the service permission. A3: Digitally sign the structured data using an immutable reference to the controller entity; A4: Output the signed structured data as the sovereign identity object.

7. The generation method according to claim 6, characterized in that, When constructing structured data in step A2, the step of normalizing the structured data is also included. The normalization process includes removing invalid spaces and sorting the key names lexicographically.

8. A method for verifying a sovereign identity object as described in any one of claims 1 to 5, characterized in that, Includes the following steps: B1: Verify the validity of the digital signature; B2: After the signature verification is successful, parse the service permission items; B3: Execute basic interactions and / or deep transactions based on the parsing results; Based on the authorization digest, the basic service endpoint identifier is verified and parsed to initiate basic interactions; The complete authorization statement is obtained based on the authorization index, and deep trading is guided according to the extended permission policy in the statement and the complex transaction server endpoint identifier.

9. The method according to claim 8, characterized in that, The basic interaction includes identity exchange operations, and the deep transaction includes performing a deterministic computation process in a specified execution environment according to the transaction rule package.