signingKeys property

Future<List<ApkamSigningKeys>> get signingKeys

The keys this client signs content with, strongest algorithm first: those of its client data signing keys that have a link, while any do, and otherwise every one it holds. Never empty: throws AtKeyNotFoundException when it holds no key to sign with, as when it has no keyfile, and a keyfile that cannot be read throws that read's error.

Which keys have a link is what rememberOwnLinkedKids last recorded; until something has, every held key signs.

Sourced from the keyfile through AtClient.atKeysIo and read on every call: a cached copy goes stale the moment an enroll:update rotates the material, and signing with a key the keyfile has retired produces a signature that verifies against nothing.

Falls back to the authentication keypair when the enrollment holds no signing material this build can sign with. apskEntries advertises that key on exactly the same condition, so what signs and what is advertised cannot drift apart.

⚠️ A mint files its new key before it publishes it, so between those two writes this answers a key the advertisement does not name yet. An envelope signed then verifies once the publish lands, or, if a stop lands first, once the next start's republish does.

Implementation

Future<List<ApkamSigningKeys>> get signingKeys async {
  final held = await heldSigningKeys;
  if (held.isEmpty) {
    return [
      await authenticationSigningKey ??
          (throw AtKeyNotFoundException('${atClient.getCurrentAtSign()} '
              'holds no key enrollment $enrollmentId can sign with'))
    ];
  }

  final linkedKids = _ownLinkedKids[atClient];
  if (linkedKids == null) return held;
  final linked = [
    for (final key in held)
      if (linkedKids.contains(publicKeyKidOfBase64(key.publicKey))) key
  ];
  return linked.isEmpty ? held : linked;
}