When a Trust Manifest appears on a Host Info object, identity
SHOULD match the host's identifier field when present.
An artifact may legitimately hold more than one verifiable identity at
+the same time, for example a SPIFFE ID for runtime workload identity
+and a DID for publisher-anchored organizational identity, or it may
+retain a former identifier after a rename or migration between
+identities or schemes. Additional identities are declared through the
+OPTIONAL alsoKnownAs member (see Optional Members).
+The identity field remains the single canonical subject identifier:
+consumers MUST use identity when referencing the artifact's trust
+subject or checking identity equivalence between entries.
When multiple entries share the same identifier (with different version
values), each entry MAY carry its own Trust Manifest. There is no
requirement that all versions carry identical trust metadata — trust
@@ -631,9 +646,48 @@
The following members are OPTIONAL:
identityTypeidentity URI (e.g., "did",
"spiffe", "dns"). This field is OPTIONAL when the type is evident
- from the URI scheme.identity; each entry of
+ alsoKnownAs carries its own identityType member.alsoKnownAsAn array of Identity Alias objects, each asserting an identity of
+ the same subject as identity under an alternative identity
+ scheme. An Identity Alias object MUST contain:
identityidentity.An Identity Alias object MAY contain:
+identityTypeidentity URI
+ (e.g., "did", "spiffe", "dns"). This member is OPTIONAL when
+ the type is evident from the URI scheme.The following rules apply:
+identity alone remains canonical and is used for
+ referencing and equivalence checking. Aliases MAY also record
+ former identifiers of the subject, preserving continuity after
+ a rename or a migration between identities or schemes.identity value, and no alias identity may
+ equal the manifest's canonical identity.identity. Aliases MAY belong to
+ different trust domains or identity schemes.signature; no per-alias proof is required. Consumers MUST NOT
+ rely on an alias from a manifest whose signature is absent or
+ fails verification (see
+ Verifying Alternative Identities).trustSchemaattestations{
"identity": "did:web:acme.com:agent:finance",
"identityType": "did",
+ "alsoKnownAs": [
+ {
+ "identity": "spiffe://acme.com/ns/finance/sa/finance-agent-pod",
+ "identityType": "spiffe"
+ }
+ ],
"trustSchema": {
"identifier": "urn:trust:acme-enterprise-v1",
"version": "1.0",
@@ -1006,6 +1066,31 @@
Manifest signature. Consumers MUST treat publisher fields as advisory
unless a verified publisher-identity attestation cryptographically
binds publisher.identifier to the signed manifest's identity.
+
+
+Verifying Alternative Identities
+Aliases need no verification procedure of their own. Because the
+signed payload covers alsoKnownAs, verifying the Trust Manifest
+signature as described in
+Trust Manifest Signatures also verifies
+every listed alias: a valid signature proves that the publisher
+controlling the canonical identity claims each alias as an
+equivalent identity of the subject. Consumers MUST NOT rely on aliases
+from a manifest whose signature is absent or fails verification.
+Signature verification itself always keys off the canonical identity:
+the verification key is resolved from identity as described in
+Trust Manifest Signatures. A consumer
+that cannot resolve the canonical identity scheme cannot verify the
+signature and therefore cannot rely on any alias.
+Once the signature is verified, a consumer MAY use whichever identity,
+canonical or alias, fits the identity schemes its tooling operates
+on. For example, after verifying the signature through a resolvable
+canonical DID identity, the consumer can use a SPIFFE ID alias to
+match the artifact's runtime workload identity.
+Note that the signature proves the publisher claims the alias, not
+that the alias's own trust domain acknowledges the link. Consumers
+making authorization decisions inside the alias's trust domain MAY
+additionally obtain proof of control native to the alias scheme.
Verifying Artifact Integrity
@@ -1555,6 +1640,7 @@
class TrustManifest {
identity string
subject Subject
+ alsoKnownAs IdentityAlias[]
trustSchema TrustSchema
attestations Attestation[]
provenance ProvenanceLink[]
@@ -1565,6 +1651,10 @@
url string
type string
digest string
+ }
+ class IdentityAlias {
+ identity string
+ identityType string
}
class TrustSchema {
identifier string
@@ -1587,6 +1677,7 @@
CatalogEntry --> "0..1" TrustManifest : trustManifest
HostInfo --> "0..1" TrustManifest : trustManifest
TrustManifest --> "0..1" Subject : subject
+ TrustManifest --> "*" IdentityAlias : alsoKnownAs
TrustManifest --> "0..1" TrustSchema : trustSchema
TrustManifest --> "*" Attestation : attestations
TrustManifest --> "*" ProvenanceLink : provenance
@@ -1711,6 +1802,7 @@
TrustManifest = {
identity: text,
? identityType: text,
+ ? alsoKnownAs: [* IdentityAlias],
? trustSchema: TrustSchema,
? attestations: [* Attestation],
? provenance: [* ProvenanceLink],
@@ -1718,6 +1810,11 @@
? termsOfServiceUrl: text,
? signature: text,
? extensions: { * text => any }
+}
+
+IdentityAlias = {
+ identity: text,
+ ? identityType: text
}
TrustSchema = {
@@ -1772,6 +1869,12 @@
"trustManifest": {
"identity": "spiffe://acme.com/ns/finance/sa/finance-a2a-pod",
"identityType": "spiffe",
+ "alsoKnownAs": [
+ {
+ "identity": "did:web:acme-corp.com:agent:finance-a2a",
+ "identityType": "did"
+ }
+ ],
"attestations": [
{
"type": "publisher-identity",