Identifiants à plusieurs champs

Les identifiants correspondent aussi au type de fiche intégré credential. La vue générique des champs associe les métadonnées non secrètes des identifiants à des champs ordinaires et les champs du corps secret à sensitive, sans réécrire les anciens octets à la lecture. memories card field prend en charge le même schéma ordonné ; les modifications réussies de champs textuels conservent le corps structuré des identifiants utilisé par les consommateurs existants. Les anciens identifiants binaires rejettent la migration générique des champs au lieu de perdre des octets.

Un identifiant peut contenir plusieurs champs indépendants et facultatifs. Ils peuvent tous être vides.

Content.credential (non secret, peut être listé sans risque) :

{
  "username": "octo",
  "url": "https://github.com",
  "notes": "work account",
  "custom": [{"name": "team", "value": "core"}],
  "secret_fields": ["password", "otp", "api_key", "pin"],
  "otp": {"digits": 6, "period": 30, "algorithm": "sha1"}
}

Corps structuré (chiffré avec le coffre, en base64url dans body) :

{"memories.credential": 2, "password": "…", "otp": "…", "api_key": "…",
 "custom": [{"name": "pin", "value": "…"}]}

Compatibilité et migration

• Les anciens identifiants conservent leurs octets secrets bruts dans body. Ils sont lus tels quels : une valeur otpauth:// ou un titre commençant par OTP: correspond à otp, un identifiant avec authentification HTTP ou hôtes autorisés correspond à api_key, et tout autre cas correspond à password. Les anciens secrets binaires (clés, certificats) continuent de fonctionner sans changement ; ils n'ont simplement aucun champ textuel.
• Chaque consommateur existant de secret unique (credential copy sans --field, injection HTTP, liaisons d'exécution, proxys, export de connexion) utilise le secret principal : les anciens octets, ou le premier élément non vide parmi password, api_key, otp et le premier champ personnalisé secret.
• La migration est différée : toute écriture credential_set sur un ancien identifiant le réécrit au format structuré, en plaçant l'ancienne valeur dans le champ correspondant. memories credential migrate VAULT ASSET effectue cette opération sans autre changement. La révision précédente reste dans l'historique : aucune donnée n'est donc perdue.

CLI

memories credential set VAULT [ASSET] [--title T] [--username U] [--url U] [--notes N]
    [--password] [--api-key] [--otp [--otp-digits 6|8] [--otp-period 30|60] [--otp-algorithm sha1|sha256|sha512]]
    [--field NAME=VALUE]... [--secret-field NAME]... [--remove NAME]...
memories credential show VAULT ASSET          # non-secret fields + names of secret fields
memories credential get VAULT ASSET --field NAME [--reveal]   # secret fields need --reveal
memories credential copy VAULT ASSET [--field NAME]           # clipboard, never printed
memories credential otp VAULT ASSET           # code from the otp field
memories credential migrate VAULT ASSET

Les valeurs secrètes sont saisies uniquement dans des invites masquées (--password, --api-key, --otp, --secret-field), jamais comme arguments. Une saisie vide efface le champ.

Requêtes de service

• credential_set {vault, asset?, title?, fields: {username?, password?, otp?, otp_params?, api_key?, url?, notes?, custom: [{name, value, secret}], remove: [name]}} — null/absent conserve un champ, "" l'efface. Exige une élévation.
• credential_show {vault, asset} — vue non secrète ; exige une élévation.
• credential_copy {vault, asset, label?, field?} — un champ (audité sous credential.field.copy) ; exige une élévation.
• otp_code {vault, asset} — accepte aussi un identifiant avec un champ otp.

Portées en mode hébergé : credential_show/credential_copy exigent la lecture, credential_set exige l'écriture.

MCP

• credential_fields (autorisation read) : champs non secrets et noms des champs secrets ; jamais les valeurs secrètes.
• credential_reveal (autorisation allow_all) : un champ ; exige intent: "reveal_plaintext" et un court reason. Audité sous credential.field.reveal. La copie du secret complet n'est pas disponible via MCP.
• sealed_reveal accepte un field facultatif pour les identifiants structurés scellés.

Center hébergé et synchronisation de bout en bout

Le RPC du Center hébergé accepte credential_show (lecture) et credential_set (écriture). Pour les identifiants de bout en bout (e2e), la copie du Center ne peut contenir que des descripteurs : credential_set rejette tout champ secret non vide et les valeurs secrètes circulent exclusivement dans des enveloppes scellées pour un appareil.

Le texte en clair d'un identifiant structuré scellé est soit le corps structuré lui-même, soit {"meta": <non-secret fields>, "body": "<structured body>"}. Sur un appareil appairé :

memories device sealed-get --vault V --card C --field username
memories device sealed-get --vault V --card C --field password --reveal
memories device sealed-get --vault V --card C --otp

Sans --reveal/--field/--otp, seuls les descripteurs et les noms des champs secrets sont affichés. Les anciennes enveloppes à secret unique se comportent comme auparavant.

Mobile

Les nouveaux identifiants ouvrent un formulaire organisé en sections (connexion, code à usage unique, API, plus, champs personnalisés avec un commutateur secret). Tous les champs sont facultatifs ; le nom prend par défaut le nom d'utilisateur ou l'hôte de l'URL et n'est demandé à l'enregistrement que s'il est encore vide. La vue détaillée copie directement les champs non secrets ; les champs secrets et le code OTP en temps réel (avec compte à rebours) exigent le verrouillage système lorsque la protection biométrique est activée.