Credenciales con varios campos

Las credenciales también son el tipo de tarjeta integrado credential. La vista genérica de campos asigna los metadatos no sensibles de las credenciales a campos ordinarios y los campos secretos del cuerpo a sensitive, sin reescribir los bytes heredados durante la lectura. memories card field admite el mismo esquema ordenado; las ediciones satisfactorias de campos de texto conservan el cuerpo de credencial estructurado utilizado por los consumidores existentes. Las credenciales binarias heredadas rechazan la migración genérica de campos en lugar de perder bytes.

Una credencial puede contener varios campos independientes y opcionales. Todos pueden estar vacíos.

Campo	Secreto	Dónde se almacena
`username`	no	`Content.credential.username`
`url`	no	`Content.credential.url`
`notes`	no	`Content.credential.notes`
personalizado, `secret: false`	no	`Content.credential.custom[]`
`password`	sí	cuerpo cifrado
`otp` (semilla base32 o URI `otpauth://`)	sí	cuerpo cifrado; parámetros de la semilla en `Content.credential.otp`
`api_key`	sí	cuerpo cifrado
personalizado, `secret: true`	sí	cuerpo cifrado

Content.credential (no secreto, se puede listar de forma segura):

{
  "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"}
}

Cuerpo estructurado (cifrado con la bóveda, base64url en body):

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

Compatibilidad y migración

Las credenciales heredadas conservan sus bytes secretos sin procesar en body. Se leen tal cual: un valor otpauth:// o un título que empieza por OTP: se asigna a otp, una credencial con autenticación HTTP o hosts permitidos se asigna a api_key, y cualquier otra se asigna a password. Los secretos binarios heredados (claves, certificados) siguen funcionando sin cambios; simplemente no tienen campos de texto.
Todos los consumidores existentes de un único secreto (credential copy sin --field, inyección HTTP, vinculaciones de ejecución, proxies, exportación de inicio de sesión) utilizan el secreto principal: los bytes heredados, o el primer valor no vacío entre password, api_key, otp y el primer campo personalizado secreto.
La migración es diferida: cualquier escritura credential_set sobre una credencial heredada la reescribe en el formato estructurado con el valor heredado colocado en el campo asignado. memories credential migrate VAULT ASSET lo hace sin ningún otro cambio. La revisión anterior permanece en el historial, por lo que no se pierden datos.

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

Los valores secretos solo se introducen mediante solicitudes de entrada oculta (--password, --api-key, --otp, --secret-field), nunca como argumentos. Una entrada vacía borra el campo.

Solicitudes al servicio

credential_set {vault, asset?, title?, fields: {username?, password?, otp?, otp_params?, api_key?, url?, notes?, custom: [{name, value, secret}], remove: [name]}} — null/ausente conserva un campo, "" lo borra. Requiere elevación.
credential_show {vault, asset} — vista no secreta; requiere elevación.
credential_copy {vault, asset, label?, field?} — un campo (auditado como credential.field.copy); requiere elevación.
otp_code {vault, asset} — también acepta una credencial con un campo otp.

Ámbito alojado: credential_show/credential_copy necesitan lectura, credential_set necesita escritura.

MCP

credential_fields (concesión de lectura): campos no secretos y los nombres de los campos secretos; nunca los valores secretos.
credential_reveal (concesión allow_all): un campo; requiere intent: "reveal_plaintext" y un reason breve. Se audita como credential.field.reveal. La copia del secreto completo no está disponible mediante MCP.
sealed_reveal acepta un field opcional para las credenciales estructuradas selladas.

Center alojado y sincronización de extremo a extremo

El RPC de Center alojado acepta credential_show (lectura) y credential_set (escritura). Para las credenciales de extremo a extremo (e2e), la copia de Center solo puede contener descriptores: credential_set rechaza cualquier campo secreto no vacío, y los valores secretos viajan exclusivamente dentro de sobres sellados por dispositivo.

El texto sin cifrar de una credencial estructurada sellada es el propio cuerpo estructurado o {"meta": <non-secret fields>, "body": "<structured body>"}. En un dispositivo emparejado:

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

Sin --reveal/--field/--otp solo se imprimen los descriptores y los nombres de los campos secretos. Los sobres heredados de un único secreto se comportan como antes.

Móvil

Las nuevas credenciales abren un formulario dividido en secciones (inicio de sesión, código de un solo uso, API, más y campos personalizados con un interruptor de secreto). Todos los campos son opcionales; el nombre toma de forma predeterminada el nombre de usuario o el host de la URL y solo se solicita al guardar si sigue vacío. La vista de detalle copia los campos no sensibles directamente; los campos secretos y el código OTP en tiempo real (con cuenta atrás) requieren el bloqueo del sistema cuando la protección biométrica está activada.