Key and Identity Safety
OAN identity is only useful if key control is real. A did:oan identifier, DID Document, or registration request should not require users to hand production private keys to a website backend. Demo flows can be convenient, but production keys need proper custody.
The rule is simple: resource holders and infrastructure operators should control their own private keys.
Key control is part of subject control. If the wrong party controls the signing key, the DID no longer gives useful assurance about the resource or node. OAN can verify signatures, but signatures only help when key custody matches real-world authority.
Demo Identity Versus Production Identity
Browser-generated identity can help a new user try registration quickly. It is useful for demos, examples, and low-risk experiments. It should be labeled as demo identity, not treated as long-term organizational identity.
Production identity should use stronger custody, such as wallets, hardware-backed keys, HSMs, enterprise secret management, secure signing services, or audited key-management workflows. The appropriate mechanism depends on the user and deployment, but private keys should not be casually copied into forms, public repositories, tickets, or chat messages.
Demo flows should expire naturally in user expectations. A resource created with temporary browser identity is fine for learning; it should not become the identity of an important public service unless the holder has a real custody and recovery plan.
Resource Holder Keys
For resource publishers, key control proves continuity. The same resource DID can carry updated package versions over time only if the holder can continue to control the relevant identity material. Losing keys may make resource updates or recovery difficult. Leaking keys may let an attacker sign misleading material.
Publishers should plan backup, rotation, and recovery before relying on a DID for important resources.
They should also decide who is allowed to publish updates. For an individual skill, that may be one maintainer. For an organizational API, it may require a release process. For a critical service, it may require separation between development keys and publication keys.
Infrastructure Operator Keys
Registrar and Discovery operators have even stronger obligations. Their keys may be used for infrastructure identity, request signing, response signing, or authorization material. Operators should keep Root keys, governance keys, node keys, server credentials, and deployment secrets separate. One compromised secret should not expose every role.
Private operational secrets belong in private secret stores and deployment processes, not public Docs or public repositories.
Operational separation matters. A cloud server password should not be the same kind of secret as a governance signing key. A node signing key should not be casually reused for unrelated services. Compartmentalization limits the blast radius of mistakes.
Website and SDK Responsibilities
The website should avoid becoming a long-term private-key custodian. If it offers demo key generation, the UI should make the scope clear. SDKs should support external signing or user-controlled key material where possible. Skills should avoid asking users to paste sensitive private keys into conversational prompts.
This is especially important because AI-assisted workflows can make unsafe secret handling feel convenient. Convenience should not erase custody boundaries.
Assistant workflows should prefer local signing, external signer integration, or explicit user-controlled files that are ignored by version control. They should never normalize the habit of pasting production private keys into prompts.
Practical Hygiene
Use .gitignore and secret scanning. Keep local .local.json files out of version control. Rotate keys if they may have been exposed. Separate cloud server credentials from governance keys. Use environment-specific configuration. Document recovery procedures privately for operators.
For public users, the most important habit is: never publish or share a production private key in order to register a resource.
If a key may have been exposed, treat it as compromised. Rotate when supported, publish updated identity material if needed, and review any packages or node actions that may have been signed during the exposure window.