Key Management for Organizational Identity

[SmithSamuelM]

Unbounded Identifiers (AIDs) and Loci of Authority

IMHO the fundamental innovative property that AIDs bring to security is that they are unbounded term identifierts (i.e persist indefinitely) this means that we can now design systems where we can strongly bind some property to that AID and that property will persist in a securely verifiable manner indefinitely in spite of key rotations and/or cryptographic algorithm changes (rotatability with crypto agility).

In organizational identity one of the most useful properties we want to bind persistently to an AID is a locus of authority.

When built properly each locus of authority adds its own root-of-trust to its trust chain. If we want the locus to persist then we want its AID to persist. Othewise we have to bespoke invent some new mechanism that most likely will be insecure. That's what federated identity has been attempting to do for decades, and they got it wrong because they didn't cryptographically bind identifiers to loci of control. They couldn't because they didn't have the concept of an unbounded term identifier.

If you look at how the legal world supports legal entities you see a structure designed to associate authority with the identifier of the organization (i.e. its legal name). This requires manual, non-cryptographically verifiable processes. With persistent cryptographic identifiers i.e. AIDS we can do a strong binding between the legal entity and its AID and build a structure of delegated authority via verifiable loci of control within the organization that persists in spite of changes of personnel. A change in personnel is a type of rotation. We want to rotate personnel without losing control over the identifier that is strongly bound to the locus of authority. So if we map personnel to keys we can rotate keys without losing control of the identifier.

Example

For example one could hire an HR employee and only given them signing authority and the HR supervisor retains rotation authority. No keys are shared. The HR employee is a custodian of their assigned AID with signing authority for that AID but that signing authority may be revoked by the supervisor by doing a key rotation. The control over the AID assigned to the HR employee may be split between signing and rotation.

Options

So we have several ways to solve the problem
HR division has group AID controlled by two loci of control, HR employee staff group AND HR supervisor group.
The keys are as follows: staff employees [e0, e1, e2, e3,] and supvervisors [s0, s1, s2]]

1. Embedded groups
   The supervisor authority is embedded in the group AID control by explicitly including the the supervisor keys with sufficient authority (weight) that removal of the staff keys does not result in loss of authority (control).
   The signing threshold is [ 1/2,1/2,1/2,1/2,1,1,1] and key list is [e0, e1, e2, e3, s0, s1, s2]

2. Nested groups

This has a threshold that looks like [[ 1,1,1,1], [1,1,1]] Where the associated keys from the associated AIDs are [[e0, e1, e2, e3,], [s0, s1, s2]] Both signing and rotation authority is split between the two groups, Every issuance and every rotation requires at least one employee and one supervisor.

3. Split signing and rotation
   Signing of issuances can be done by any HR employee but key rotation of the AID can only be done by a supervisor

The signing threshold is [1, 1,1,1] for keys from AIDS [[e0, e1, e2, e3,] and the rotation threshold is [1,1,1] for keys from AIDs [s0, s1, s2]

4. Nested groups and split signing and rotation

In this case supervisors can both sign and rotate but employees may only sign. It issuance requires both employee and supervisor signatures

The signing threshold is

[[ 1,1,1,1], [1,1,1]] for keys from AIDS [[e0, e1, e2, e3,], [s0, s1, s2]] and the rotation threshold is [1,1,1] for keys from AIDs [s0, s1, s2]

Organization Level EGF

The ecosystem governance framework for that organization and those is does business with (i.e. its business ecosystem)
could specify that an HR employee must have a credential issued to a given AID whose key had signing authority at the time of issuance and there might be a chain of authority for that credential that must be unbroken at the time of issuance. Because credentials can have issuance dates and revocation registies (TELs) can have issuance and revocation dates one can then map the date logic for preserving the timeliness of the credential issuances for authority.

[edeykholt]

@dhh1128 today on the ACDC call led a discussion around aliases for organizational identity using a particular credential scheme convention, such as "Cecilia as CEO at Acme". IMO, there could be formalization of the concept of Credential Schemes and the generic structure for them described in or on top of the ACDC spec, with this particular credential scheme and alias convention noted as non-normative guidance.