Feature: Allow `xid service add` to embed encrypted private keys

[ChristopherA]

xid service add currently only accepts public key references via --key. There's no way to add a private key to a service and have it encrypted for secure storage.

xid key add supports this with --private encrypt, but services can only reference keys—they can't include key material directly.

The Gap

# xid key add supports encrypted private keys:
envelope xid key add --private encrypt "$PRVKEYS" "$XID_DOC"

# xid service add does not:
envelope xid service add --key "$PUBKEYS" ...  # public reference only

Proposed

Add --private option to xid service add, matching the existing xid key add interface:

XID_DOC=$(envelope xid service add \
    --name "GitHub" \
    --prvkeys "$PRVKEYS" \
    --private encrypt \
    --password "$PASSWORD" \
    "https://github.com/username" \
    "$XID_DOC")

The key would be created, encrypted, and automatically referenced by the service.

Use Case: GitHub with SSH Signing Keys

Linking a GitHub account requires an SSH signing key (not the XID's inception key). Key separation matters here—the SSH key is service-specific and should be:

• Generated using --signing ssh-ed25519 (or other SSH types)
• Importable from existing OpenSSH key files via envelope import
• Encrypted at rest in the XID document
• Scoped to the GitHub service only

# Import existing SSH key from ~/.ssh
SSH_PRVKEYS=$(envelope import <~/.ssh/id_ed25519)

# Add GitHub service with encrypted SSH private key
XID_DOC=$(envelope xid service add \
    --name "GitHub" \
    --prvkeys "$SSH_PRVKEYS" \
    --private encrypt \
    --allow sign \
    "https://github.com/username" \
    "$XID_DOC")

The SSH key signs commits and proves account control. It can be exported to OpenSSH format (envelope export) for use with git. If compromised, the service key can be rotated without affecting the XID's core identity keys.

Suggested Options

Option	Purpose
--prvkeys <UR>	Private keys to embed in the service
--private encrypt	Encrypt the private key material
--password / --askpass	Password for encryption
--key-nickname <NAME>	Optional nickname for the key

Current Workaround

Two-step process:

XID_DOC=$(envelope xid key add --private encrypt "$PRVKEYS" "$XID_DOC")
XID_DOC=$(envelope xid service add --key "$PUBKEYS" ... "$XID_DOC")

This works but separates what users think of as one operation: "add a service with its encrypted signing key."

cc @shannona

[ChristopherA]

Possibly the service should be signed by the service signing key as well, as a proof-of-control of the signing key. /cc @shannona -- what do you think?

[wolfmcnally]

The intention was that all the 'key' assertions in a XID document formed a sort of "key chain" while other secondary assertions like 'service' only referred to the keys in the chain. This is so that each key can be managed at the top level cleanly, and carries a transparent set of permissions. You add a key to your XID document, then refer to it one or more places elsewhere in the document. This allows you to manage all your keys in one place rather than having to manage them at arbitrarily deeply nested positions.

[shannona]

Proof of control seems vitally important for a service, so you can prove that the controller of a XID is also the controller of the service. The use case would be GitHub. You point to your GitHub user account as a service, and then if you can prove you control that account, you prove the XID is linked to all the work in the repos.

More generally, this is a list of content that Christopher and I had in our details of a GitHub account.

GITHUB_ACCOUNT=$(envelope assertion add pred-obj known isA string "GitHubAccount" "$GITHUB_ACCOUNT")
GITHUB_ACCOUNT=$(envelope assertion add pred-obj known conformsTo string "https://github.com" "$GITHUB_ACCOUNT")
GITHUB_ACCOUNT=$(envelope assertion add pred-obj known dereferenceVia uri "https://api.github.com/users/$XID_NAME" "$GITHUB_ACCOUNT")
GITHUB_ACCOUNT=$(envelope assertion add pred-obj string "sshSigningKeysURL" uri "https://api.github.com/users/$XID_NAME/ssh_signing_keys" "$GITHUB_ACCOUNT")
GITHUB_ACCOUNT=$(envelope assertion add pred-obj string "sshSigningKey" ur "$SSH_PUBKEYS" "$GITHUB_ACCOUNT")
GITHUB_ACCOUNT=$(envelope assertion add pred-obj string "sshSigningKeyText" string "$SSH_EXPORT" "$GITHUB_ACCOUNT")
GITHUB_ACCOUNT=$(envelope assertion add pred-obj string "sshSigningKeyProof" envelope "$PROOF" "$GITHUB_ACCOUNT")
CURRENT_TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%SZ)
GITHUB_ACCOUNT=$(envelope assertion add pred-obj string "createdAt" date "$CURRENT_TIMESTAMP" "$GITHUB_ACCOUNT")
GITHUB_ACCOUNT=$(envelope assertion add pred-obj string "updatedAt" date "$CURRENT_TIMESTAMP" "$GITHUB_ACCOUNT")

If the service function is going to be deeply constrained and not allow the inclusion of envelopes, then we need to consider whether this other data should be available as standard functions for a service, specifically:

• Separate URLs for main site and user account [as Chris has here, the latter might be a 'derefenceVia']
• Separate entries for included public key as UR, text, and URL at service
• Time stamp for creation of service
• Time stamp for update of service
• Way to prove ownership of private key linked to public key incorporated into service

[wolfmcnally]

The idea behind services, as originally described to me by Christopher and as implemented by me in architecture and code, is that a XID document has a set of keys and a set of services advertised that use those keys. The keys themselves have a set of permissions that may constrain what services are allowed to do with them, and a single key could be used across several services, or each key could be used by a single service. The service itself was supposed to be simple, like a URI with a known protocol for working with it.

It was not designed to operate with legacy protocols that were not designed with XID Documents in mind.

If you and Christopher want to re-architect this now, then go right ahead. But what I designed and implemented is in fact what was asked for originally.