Request Attributes

A request attribute turns a regular attribute into a declaration of certificate content. It is a DataAttributeV3 that carries a fieldMapping. The presence of the mapping is the sole marker: an attribute without a fieldMapping behaves exactly as before, so existing definitions keep working unchanged.

For the concept — why request attributes exist and how the platform resolves the effective set — see Request Attribute. For the connector wire contract, see Structured Certificate Request Content. The model classes can be found in the Interfaces repository.

fieldMapping

The fieldMapping declares which certificate (or other object) fields the attribute's value projects into. It has two properties, both required:

• objectType — the object type this mapping applies to. Only x509Certificate is built today. The codes sshCertificate, key, and secret are reserved — the model stays open for other object types.
• fields — one or more target fields. The mapping is 1-to-many: a single attribute value can project into several fields at once, for example the subject CN and a DNS SAN entry.

Mapped fields

Each entry in fields is a MappedField, polymorphic on fieldType. Three properties are common to all field types:

• fieldType — the discriminator: rdn, san, or extension.
• order — ordering index among fields of the same type, ascending. It orders the fields within this definition's mapping; across definitions, the subject follows the order the definitions appear in the resolved set.
• source — the intended provenance of the value when a client CSR and platform-supplied values both offer the field: csr, platform, or csrThenPlatform (CSR first, platform as fallback). Reserved — stored but not evaluated yet; do not rely on it.

The three field types:

• rdn — maps the value to a subject DN component. Carries rdn — a short code (for example CN) or a dotted-decimal OID, resolved through the OID registry.
• san — maps the value to a Subject Alternative Name entry. Carries generalNameType. When the type is otherName, it also carries otherNameOid and otherNameValueEncoding, because different OtherName OIDs carry differently typed values.
• extension — maps the value to an X.509 extension. Carries extensionOid (dotted-decimal; must be known to the Certificate Extension category of the OID registry — either built in or registered as a Custom OID) and criticalOverridable — whether the requester may override the extension's default criticality. criticalOverridable is reserved — stored but not evaluated yet; criticality always follows the registry's default.

valueSource

Orthogonal to the mapping, valueSource declares how the platform resolves the attribute's content. Its kind is one of:

• none — free input; the requester types any value.
• staticList — the requester picks from a fixed list defined with the attribute.
• connectorCallback — the list of values is supplied dynamically by a connector callback. Defined in the model but not offered in the authoring UI, which exposes only free input and static list.

The model also defines dependency params that scope the source by other attributes' values. They are stored but not evaluated yet — do not rely on them.

Example

A "Server FQDN" request attribute. One value projects into both the subject CN and a DNS SAN entry:

{
  "uuid": "c7a8f8f0-f8f8-4f8f-8f8f-f8f8f8f8f8f8",
  "name": "serverFqdn",
  "type": "data",
  "version": 3,
  "schemaVersion": "v3",
  "contentType": "string",
  "description": "Fully qualified domain name of the server",
  "properties": {
    "label": "Server FQDN",
    "required": true,
    "readOnly": false,
    "visible": true,
    "list": false,
    "multiSelect": false,
    "group": "Certificate Identity"
  },
  "fieldMapping": {
    "objectType": "x509Certificate",
    "fields": [
      {
        "fieldType": "rdn",
        "rdn": "CN",
        "order": 1
      },
      {
        "fieldType": "san",
        "generalNameType": "dns",
        "order": 1
      }
    ]
  },
  "valueSource": {
    "kind": "none"
  }
}