Operations
DSNP implementations perform well-defined DSNP Operations and generate DSNP State Change Records.
Control Keys and Proofs
Each invocation of a DSNP Operation MUST have verifiable approval of the acting principal(s) via a Control Key Ownership Proof. The precise data type and representation of both the Control Key and the Control Key Ownership Proof MUST be defined by each DSNP implementation. For example, an implementation might use the public key of an asymmetric key pair as a control key, and provide a proof for each operation by producing a cryptographic signature of the user’s DSNP Identifier and some nonce value.
Where operations are listed as using control keys or ownership proofs as input parameters, this indicates that these keys or proofs should be provided in addition to those needed for invocation authentication.
Transaction Identifiers
Each invocation of a DSNP Operation should be associated with a Transaction Identifier. Transaction Identifiers are used to associate Operation invocations with asynchronously emitted State Change Records. It MUST be possible to associate a DSNP State Change Record with a Transaction Identifier from a particular DSNP Operation invocation. Transaction Identifiers MUST be unique within an implementation. Transaction Identifiers MUST be serializable as a string.
Failure Handling
Compliant implementations may respond to error conditions either synchronously, as a response to the invocation request, or asynchronously, by emitting a Failure Record.
List of Operations
| Operation | Optional? | Principal(s) | Inputs | State Change Record or Output |
|---|---|---|---|---|
| Create Identifier | no | None | Control Key, Control Key Ownership Proof | Identifier Creation Record |
| Retire Identifier | no | User | None | Identifier Retirement Record |
| Define Delegation | no | User AND Delegate | User’s Identifier, Delegate’s Identifier, Set of Allowed Announcement Types, Set of Allowed User Data Types | Delegation Definition Record |
| Revoke Delegation | no | User OR Delegate | User’s Identifier, Delegate’s Identifier | Delegation Revocation Record |
| Add Control Key | YES | User | Key, Key Ownership Proof | Control Key Addition Record |
| Remove Control Key | YES | User | Key | Control Key Removal Record |
| Publish Announcement | no* | User OR Delegate | Announcement | Announcement Published Record |
| Publish Batch | no* | User OR Delegate | Announcement Type, Batch Publication URL, Batch Publication Content Hash | Batch Published Record |
| Get User Data | no | Any | User’s Identifier, Set of Requested User Data Types | Map of User Data Types to Data Chunks with optional key identifiers of encryption keys for each chunk |
| Replace User Data | no | User OR Delegate | User’s Identifier, Key Identifier, Map of User Data Types to Data Chunks | User Data Replaced Record |
* For each Announcement Type, an implementation may support one or both of these operations. Implementations MUST document which of the operations is available for each Announcement Type.