@ccmsg/protocol 2.4.0 → 2.5.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ccmsg/protocol",
-  "version": "2.4.0",
+  "version": "2.5.0",
   "description": "Wire contract (schema + types + op attribute table) shared by the ccmsg daemon and web UI",
   "license": "MIT",
   "author": "kawaz",

package/src/common/auth.ts

@@ -146,6 +146,43 @@ const ENROLL_CLAIMS_FIELDS = {
    * own device is `device_label` on the record, and the two are worth telling
    * apart when a list is read back later. */
   issued_label: Type.Optional(Type.String({ maxLength: 128 })),
+  /** What to call the account in the authenticator, as the administrator who
+   * made the URL wrote it.
+   *
+   * It has to travel, because the page has to name the account before anything
+   * is created and has no other way to learn it: a passkey manager keeps the
+   * name the ceremony was given and shows it wherever the key is listed, so a
+   * URL that carried none would put the user handle — sixteen random bytes — in
+   * front of the person at every sign-in.
+   *
+   * Apart from `issued_label`, which is a note about who the URL was handed to
+   * and stays on the credential as exactly that. One value answering both would
+   * be an administrator's private memo shown to the person as their own name,
+   * with no way to correct either without the other.
+   *
+   * A starting point and not the answer: the registration form shows it and the
+   * person may say otherwise, and `auth.register.display_name` is what they
+   * settled. For a URL adding a passkey to somebody who exists, it is the name
+   * they already read themselves by, so a second key joins the same account. */
+  display_name: Type.Optional(Type.String({ maxLength: 128 })),
+  /** Every instance this enrolment hands the person, written by whichever one
+   * the ceremony lands on once it succeeds.
+   *
+   * The set is decided at the terminal that made the URL, because that is where
+   * "the instances this one knows of" is a question anybody can see the answer
+   * to. It has to travel, for the same reason the rest of the claims do: behind
+   * a load balancer the ceremony lands wherever it lands, and an instance that
+   * wrote the grantings it happened to know of would answer a different
+   * question than the one that was asked.
+   *
+   * Written when the enrolment succeeds and not before. A granting for somebody
+   * who never registered would sit in the replicated set naming a person no
+   * user record answers for — inert, since nothing could authenticate as them,
+   * but there to be read and impossible to tell from one that means something.
+   *
+   * Absent is the issuer's own instance alone, which is what `instance` already
+   * says. Naming it here as well is how a URL hands over more than one. */
+  instances: Type.Optional(Type.Array(InstanceId)),
 } as const;
 
 /** What an enrolment URL carries, as the instance that issued it reads it back.
@@ -220,6 +257,19 @@ export const AuthRegisterArgs = Type.Object({
   /** What the person calls the device they are registering, for their own use
    * when they later read back a list of several. Nothing is decided by it. */
   device_label: Type.Optional(Type.String({ maxLength: 128 })),
+  /** What the person settled on being called, from the form the registration
+   * page showed them with the URL's `display_name` already in it.
+   *
+   * Here rather than left to the claims because the person is the one it is
+   * about: an administrator issuing the URL guesses at a name, and the person
+   * in front of the browser is who can say. It is what the authenticator was
+   * given as the account name, so what they see in their passkey manager and
+   * what they read themselves by here are the same string.
+   *
+   * Unstated leaves the claims' value standing. It authenticates nothing, like
+   * every other name here. Adding a passkey to somebody who already exists does
+   * not rename them — the account it joins is one they have already named. */
+  display_name: Type.Optional(Type.String({ maxLength: 128 })),
   /** The challenge this registration answers, with the instance that can spend
    * it — the same pairing an assertion carries, and for the same reason: the
    * value also sits inside `client_data_json`, but who may consume it does not,

package/src/fixtures/common.ts

@@ -212,6 +212,7 @@ export const AUTH_REGISTER_REQUEST: Static<typeof AuthRegisterRequest> = {
   token: ENROLL_TOKEN,
   code: ENROLL_CODE,
   device_label: "work laptop",
+  display_name: "kawaz",
   challenge: CHALLENGE,
   credential: {
     id: "Y3JlZC1pZA",
@@ -390,9 +391,10 @@ export const AUTH_RESOLVE_REQUEST = {
 } satisfies Static<typeof AuthResolveRequest>;
 
 /** What the issuer answers about a URL that makes a person. It names the user
- * the credential will be created against, and posts to the address in front of
- * the instances rather than to the issuer's own — whichever of them the answer
- * lands on completes it. */
+ * the credential will be created against, posts to the address in front of the
+ * instances rather than to the issuer's own — whichever of them the answer
+ * lands on completes it — and names both instances the person is to own, which
+ * the receiver writes the grantings for. */
 export const AUTH_RESOLVE_RESPONSE = {
   ok: true,
   request_id,
@@ -407,6 +409,8 @@ export const AUTH_RESOLVE_RESPONSE = {
     jti: "01J9Z3W2Q",
     user: USER,
     issued_label: "for kawaz",
+    display_name: "kawaz",
+    instances: [instance, other_instance],
   },
 } satisfies Static<typeof AuthResolveResponse>;
 
@@ -425,6 +429,8 @@ export const AUTH_RESOLVE_ADD_OWNER_RESPONSE = {
     expires_at: FIXTURE_NOW + 600_000,
     jti: "01J9Z3W2R",
     issued_label: "nuc, for kawaz",
+    display_name: "kawaz",
+    instances: [other_instance],
   },
 } satisfies Static<typeof AuthResolveResponse>;