@ai-ecoverse/slicc-vault 1.15.0 → 1.15.1

package/README.md

@@ -352,7 +352,7 @@ It answers `{ values: { [placeholder]: value } }` for those, and leaves the othe
 
 **pg SCRAM-SHA-256** (`position: 'scram-sha-256'`, §3.19.5). The program's pg client computes its `ClientProof` from the password it holds, a placeholder, so the kernel can't see which one it used; the vault finds it from the proof. The request carries `scram: { clientFirstBare, serverFirst, clientFinalBare, proof }` and no `placeholders` (`EINVAL` otherwise, and `scram` at any other position is `EINVAL` too):
 - `clientFirstBare` is `n=<user>,r=<client nonce>` and `serverFirst` is `r=<nonce>,s=<salt>,i=<iterations>`, with no extensions; the server's nonce must extend the client's, and `i` must be 1 to 100000.
-- `clientFinalBare` is `c=biws,r=<the server's nonce>`, without `p=`: `biws` is the GS2 header `n,,`, so channel binding (`-PLUS`, `p=…`, `y,,`) is refused. The kernel offers the program only `SCRAM-SHA-256`, because the program's binding data couldn't match the kernel's TLS.
+- `clientFinalBare` is `c=<base64>,r=<the server's nonce>`, without anything after. `c=` decodes to exactly one of three things: the GS2 header `n,,` (`biws`); `y,,` (`eSws`, the program supports binding but saw no `-PLUS`); or `p=tls-server-end-point,,` followed by binding data of a SHA-256, -384 or -512 digest's length (32, 48 or 64 bytes), when the kernel offered the program `SCRAM-SHA-256-PLUS`. The binding data is opaque: it's used only as part of the program's AuthMessage, exactly as sent, to match the placeholder's proof, and it is never returned, logged or audited. Any other `p=` type (`tls-unique`, `tls-exporter`), an authzid, another length, or a malformed or non-canonical `c=` (it must re-encode to itself) is `EINVAL` before the burn.
 - `proof` is base64 of the program's 32-byte `ClientProof`. Each message is at most 1024 characters. Anything else is `EINVAL`, before the burn.
 
 The candidates are the placeholders that would pass the per-placeholder checks above for this session (a live `secret` with a `scram-sha-256` session rule for this host and port, whose `[exits]` allow `exit`), never other records; more than 16 is `EACCES` "more than 16 session rules' placeholders to try for SCRAM", before any hashing. For each, the vault computes RFC 5802's `ClientProof` with the placeholder as the password (PBKDF2-SHA-256 over the salt and iterations, then the Client Key, Stored Key and signature over `clientFirstBare,serverFirst,clientFinalBare`) and compares it in constant time. Only placeholders are hashed, never values, so it reveals nothing the program doesn't hold. Exactly one match is handed out as above (re-checked at release, audited with `position: 'scram-sha-256'`); none is `EACCES` "no session rule's placeholder matches the SCRAM proof", and more than one is `EACCES` "more than one placeholder matches the SCRAM proof". The kernel computes the real proof from the value, checks the server's real `v=` before giving the program one made from the placeholder, never passes on a server `e=` derived from the value, and wipes the value and every derived key.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ai-ecoverse/slicc-vault",
-  "version": "1.15.0",
+  "version": "1.15.1",
   "description": "The separate-origin vault at vault.sliccy.ai: sealed secrets, OAuth tokens, and model and MCP credentials for SLICC seven, used only by its injector",
   "piAi": "1.3.0",
   "type": "module",
@@ -48,9 +48,9 @@
   },
   "devDependencies": {
     "@ai-ecoverse/jerk-oauth": "1.0.0",
-    "@ai-ecoverse/slicc-kernel": "1.132.1",
+    "@ai-ecoverse/slicc-kernel": "1.133.5",
     "@ai-ecoverse/slicc-scrub": "1.0.0",
-    "@ai-ecoverse/slicc-shared-web": "1.25.1",
+    "@ai-ecoverse/slicc-shared-web": "1.27.0",
     "@ai-ecoverse/wasm-bash": "5.3.0-21",
     "@ai-ecoverse/wasm-coreutils": "9.12.0-10",
     "@biomejs/biome": "2.5.15",