You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FabToken is a straightforward implementation of the Driver API.
4
+
It prioritizes simplicity over privacy, storing all token transaction details openly on the ledger for anyone with access to view ownership and activity.
5
+
FabToken exclusively supports long-term identities based on a standard X.509 certificate scheme,
6
+
which reveals the owner's enrollment ID in plain text.
7
+
Tokens are directly represented on the ledger as JSON-formatted data based on the `token.Token` structure.
8
+
The `Owner` field of this structure stores the identity information.
9
+
The `Identity Service` handles the encoding/decoding of this field.
10
+
11
+
## Security
12
+
13
+
`FabToken` does not provide privacy for tokens or identities.
14
+
The validator guarantees the following:
15
+
***Issuer Authorization**: Only issuers listed in the public parameters can issue tokens.
16
+
***Auditor Authorization**: Only auditors listed in the public parameters can audit transactions.
17
+
***Owner Authorization**: Only legitimate owners can spend their tokens.
18
+
***Value Preservation**: In a transfer, the sum of inputs matches the sum of outputs.
The **Identity Service** (`token/services/identity`) provides a unified interface for managing identities, signatures, and verification within the Fabric Token SDK. It abstracts the underlying cryptographic details, allowing the SDK to support multiple identity types (e.g., X.509, Idemix) and different storage backends seamlessly.
3
+
The **Identity Service** (`token/services/identity`) provides a unified interface for managing identities, signatures, and verification within the Fabric Token SDK.
4
+
It abstracts the underlying cryptographic details, allowing the SDK to support multiple identity types (e.g., X.509, Idemix) and different storage backends seamlessly.
4
5
5
6
This service is a fundamental component used by token drivers and other services (like the Token Transaction (TTX) service) to handle:
6
7
***Signatures**: Generating and verifying signatures for transactions.
@@ -10,87 +11,177 @@ This service is a fundamental component used by token drivers and other services
10
11
11
12
## Architecture
12
13
13
-
The core of the service is the `Provider` struct, which implements the `driver.IdentityProvider` interface. It orchestrates interactions between:
14
-
15
-
1.**Storage**: Persists identity data, including audit information, secrets (via keystore), and bindings between wallets and identities.
16
-
2.**Deserializers**: Parses raw identity bytes into typed identity structures (e.g., converting an Idemix byte array into a usable object).
17
-
3.**Signers and Verifiers**: Interfaces for cryptographic operations.
18
-
4.**Binder**: Handles binding long-term identities to ephemeral ones.
19
-
20
-
### Key Components
21
-
22
-
***`Provider`** (`token/services/identity/provider.go`): The main entry point. It manages caches for signers and "is-me" checks to optimize performance.
23
-
***`Storage`** (`token/services/identity/driver/storage.go`): Interface for the underlying storage. It handles storing and retrieving audit info, token metadata, and signer info.
24
-
***`Role`** (`token/services/identity/driver/role.go`): Defines abstract roles (Issuer, Auditor, etc.) and how they map to long-term identities.
25
-
26
-
## Identity Types
27
-
28
-
The service supports multiple identity types, extensible via drivers. The two primary built-in types are:
14
+
The Identity Service is designed to implement the **Driver API** interfaces defined in `token/driver/wallet.go`.
15
+
This ensures that the token management system can interact with any identity implementation through a standard set of methods.
16
+
17
+
### Conceptual Metaphor
18
+
19
+
To better understand the components, imagine a **Corporate Security Department**:
20
+
21
+
***Identity Service (The Department)**: The entire division responsible for security and access.
22
+
***Wallet Service (The Keymaster)**: Maintains a registry of all employees (Wallets) and the badges (Keys) they possess. It knows who has access to what.
23
+
***Identity Provider (The Passport Office)**: Verifies identities. It checks if a badge is authentic and extracts information from it (Project ID, Department ID).
24
+
***Roles (Job Titles)**: Groups of employees with similar access rights (e.g., "Auditors" have special keys to view records, "Issuers" have keys to create assets).
25
+
***Key Managers (The Badge Makers)**: The specific machines or protocols used to create the badges (e.g., one machine makes standard plastic cards (X.509), another makes high-tech smart cards (Idemix)).
26
+
27
+
### Component Mapping
28
+
29
+
Here is how the service components map to the Driver API:
note for identity.Provider "Handles low-level crypto\nand identity verification"
90
+
note for wallet.Service "High-level management\nof wallets and roles"
91
+
```
29
92
30
-
### 1. X.509
31
-
Standard PKIX identities.
32
-
***Transparency**: Identity is known.
33
-
***Usage**: Typically used for component identification (e.g., orderingers, peers) or when anonymity is not required.
34
-
***Implementation**: Located in `token/services/identity/x509`.
93
+
### LocalMembership
35
94
36
-
### 2. Idemix (Identity Mixer)
37
-
Zero-Knowledge Proof (ZKP) based identities.
38
-
***Anonymity**: Allows users to prove possession of a credential without revealing the credential itself.
39
-
***Unlinkability**: Transactions cannot be linked to the same user.
40
-
***Auditability**: Special "audit info" allows authorized auditors to reveal the identity if needed.
41
-
***Implementation**: Located in `token/services/identity/idemix`.
95
+
The `LocalMembership` component (`token/services/identity/membership`) plays a pivotal role in managing local identities for a specific role (e.g., Owner, Issuer).
42
96
43
-
## Usage
97
+
***Binding**: Each instance is bound to a list of **Key Managers**.
98
+
***Identity Wrapping**: When a Key Manager generates an identity (based on the configuration), `LocalMembership` automatically wraps it using `WrapWithType`.
99
+
This ensures that the generated identity carries the correct type information required by the system (as defined in `token/services/identity/typed.go`).
100
+
***Role Implementation**: `LocalMembership` serves as the foundational implementation for `role.Role`.
101
+
When you interact with a Role to resolve an identity or sign a transaction, you are effectively delegating to the underlying `LocalMembership`.
44
102
45
-
### Retrieving the Identity Provider
46
-
The Identity Provider is usually accessed via the `Token Management Service` (TMS) API or injected into other services.
103
+
### Example: Wiring Services
47
104
48
-
### Getting a Signer
49
-
To sign a message with a specific identity:
105
+
The following example demonstrates how these services are instantiated and wired together, as seen in the ZKATDLog driver:
50
106
51
107
```go
52
-
// identity is of type driver.Identity (byte array)
// 5. Create Wallet Service with the registered roles
135
+
return wallet.NewService(
136
+
logger,
137
+
identityProvider,
138
+
deserializer,
139
+
// Convert the roles registry into the format expected by the wallet service
140
+
wallet.Convert(roles.Registries(...)),
141
+
), nil
56
142
}
57
-
58
-
signature, err:= signer.Sign(message)
59
143
```
60
144
61
-
### Verifying a Signature
62
-
Unless you have the `Verifier` directly, verification often happens implicitly during transaction processing or via the `Deserializer` if you need to manually verify:
To check if a given identity belongs to the local node (i.e., we have the private key for it):
147
+
The Identity Service leverages a wrapper called **TypedIdentity** to support various identity schemes uniformly.
148
+
This allows the SDK to be extensible and capable of handling different cryptographic requirements.
75
149
76
-
```go
77
-
if identityProvider.IsMe(ctx, identity) {
78
-
// This identity is managed by this node
79
-
}
80
-
```
150
+
### TypedIdentity
81
151
82
-
### Audit Information
83
-
For anonymous identities (Idemix), "Audit Information" is a crucial concept. It contains the data needed to de-anonymize the identity (e.g., to checking against a revocation list or for regulatory auditing).
152
+
`TypedIdentity` (defined in `token/services/identity/typed.go`) acts as a generic container.
153
+
It wraps the raw identity bytes with a type label, enabling the system to verify deserializers and process signatures correctly without hardcoding implementation details.
154
+
***Structure**: Contains a `Type` (string) and the `Identity` (raw bytes).
***Signers**: Once deserialized/created, signers are cached to avoid expensive re-initialization.
93
-
***"Is Me" Checks**: Results of ownership checks are cached to speed up transaction filtering.
158
+
The identity service includes two primary implementations for concrete identities:
94
159
95
-
## Integration with Drivers
96
-
Token drivers (like the UTXO driver) heavily rely on this service. They delegate identity management tasks to it, ensuring that the driver code remains agnostic to the specific identity technology (X.509 vs Idemix) being used.
160
+
#### 1. X.509
161
+
Standard PKIX identities.
162
+
***Transparency**: Verification reveals the identity of the signer.
163
+
***Usage**: Ideal for infrastructure components (nodes, services) or scenarios where anonymity is not required.
0 commit comments