A SATP Core Binding for vLEI Identities

4.1.1. LegalEntityIdentityvLEICredential Credentials

The SATP Messages in row 1 of Table 3 is a LegalEntityvLEICredential as defined by the LEvLEIC schema.¶

These messages are realized using a Legal Entity vLEI Credential (LEvLEIC) because these message identify legal entities. Gateway owner identities area form of legal entity as they identify the owner of a gateway rather than the gateway itself.¶

4.1.2. LegalEntityEngagementContextRolevLEICredential Credentials

The SATP Messages in row 3 of Table 3 is a LegalEntityEngagementContextRolevLEICredential as defined by the LEECRvLEIC schema.¶

These messages are realized using a LEECRvLEIC because they identify the gateways and hosts within the respective networks involved in transferring digital assets.¶

4.1.3. Other vLEI Deployment Considerations

SATP deployments could utilize other vLEI roles. For example, an ECR role might be defined for a SATP Gateway Operations Manager or Network Administrator. See row 3 Table 3. Although SATP Stage 1 messages don't directly refer to ECR credentials, the credentials referenced could link to ECR credentials which in turn link to ECRA credentials etc...¶

4.3.1. SATP Transfer Initiation (Stage 1) Message Binding

The SATP stage 1 messages containing identifiers use a vLEI wrapper that contains a payload and payload content identifier. Other stage 1 messages are public key values that use a key wrapper that disambiguates the key type and format or can be expressed as a wrapped vLEI.¶

satp-message = {
  ? verifiedOriginatorEntityId: wrapped-vlei
  ? verifiedBeneficiaryEntityId: wrapped-vlei
  ? senderGatewayOwnerId: wrapped-vlei
  ? receiverGatewayOwnerId: wrapped-vlei

  ? senderGatewayId: wrapped-vlei
  ? recipientGatewayId: wrapped-vlei
  ? senderGatewayNetworkId: wrapped-vlei
  ? recipientGatewayNetworkId: wrapped-vlei

  ? originatorPubkey: wrapped-vlei / wrapped-key
  ? beneficiaryPubkey: wrapped-vlei / wrapped-key
  ? senderGatewaySignaturePublicKey: wrapped-vlei / wrapped-key
  ? receiverGatewaySignaturePublicKey: wrapped-vlei / wrapped-key
  ? senderGatewayDeviceIdentityPubkey: wrapped-vlei / wrapped-key
  ? receiverGatewayDeviceIdentityPubkey: wrapped-vlei / wrapped-key
}

4.3.2. vLEI Wrapper

; =====================================================================
; --- Wrapped vLEI Payloads ---
; =====================================================================

wrapped-vlei = {
 content: content-ref
 payload: bstr / tstr
}

4.3.3. Content References

content-ref = non-empty<{
 ? mt: vlei-media-type ; TBA
 ? cf: uint ; TBA content format id
 ? cbt: bool ; payload contains CBOR tagged content in the TN() range if true, if false not cbor tagged and "mt" is required
 ? oid: tstr ; generated from content-format-id e.g., "1.3.6.1.4.1.37476.2.1.5"
}>

4.3.4. Key Wrappers

; =====================================================================
; --- Wrapped Key Definitions ---
; =====================================================================

wrapped-key = $key-type
$key-type /= cose-key
$key-type /= jwk-key
$key-type /= pkix-key

cose-key = {
 content: "application/cose;cose-type=cose-key" / uint,
 encoding: "cbor" / "base64uri" / "text",
 payload: bstr / tstr
}

jwk-key = {
  content: "application/jwk+json" / uint,
  payload: tstr
}

pkix-key = {
  content: "application/pkix-cert" / uint,
  encoding: "PEM" / "DER",
  payload: tstr / bstr
}

4.4.1. Profile Optonal Parameter

The media type assignments have an optional parameter named "profile=" that MAY be any value. It can be used to identify a vLEI profile such as vLEI credential type. It SHOULD be expressed in URI format as illustrated in Table 5.¶

The various vLEI credential types can be specified in a media type using the profile option. Table 5 summarizes the profile identifiers for the various vLEI credential types. A comprehensive listing of vLEI profiles is provided even though some of the vLEI credential types are not anticipated by the vLEI binding to SATP at this time.¶

4.4.2. Encoding Optonal Parameter

The media type assignments have an optional encoding ("encoding=") parameter that can be used to tunnel an alternative encoding. Typically, encodings fall into two broad categories; text or binary. An encoding MAY be any value, but RFCthis anticipates the following:¶

• "base64uri" -- the payload is binary, as indicated by the media-type, but base64 encoded when the bounding protocol is a text stream. See Section 5, [RFC4648].¶

4.4.3. Charset Optonal Parameter

The media type assignments have an optional character set ("charset=") parameter that can be used to identify the character encoding scheme when the payload is a text encoding. By default "utf-8" is assumed. Alternative character set encodings MUST populate "charset=".¶

8.1.1. application/cesr+json

This media type indicates the payload is a JSON formatted vLEI.¶

Type name:¶

• application¶

Subtype name:¶

• cesr+json¶

Required parameters:¶

• None¶

Optional parameters:¶

• profile — Indicates the payload conforms to a specific vLEI credential type.¶

• encoding — Indicates the ACDC stream is text or binary. If binary, encoding MUST make the payload text-safe (e.g., encoding=base64uri). Defaults to text.¶

• charset — Indicates character set for text encodings. Defaults to UTF-8.¶

Encoding considerations:¶

• 8-bit; JSON text encoding defaults to UTF-8.¶

• Binary payloads are text-safe encoded for use in JSON streams.¶

Security considerations:¶

• See Section 7.¶

Interoperability considerations:¶

• Binary payloads must be base64 encoded to make payloads compatible with text streams.¶

• Section 9.4 and 9.5 in the CESR specification (cold start) in CESR¶

• Section 11.5 Version String Field in CESR¶

Published specification:¶

• RFCthis¶

• Key Event Receipt Infrastructure (KERI) — [KERI-Spec]¶

• Authentictic Chained Data Containers (ACDC) — [ACDC-Spec]¶

• Composable Event Streaming Representation (CESR) — [CESR-Spec]¶

• GLEIF vLEI Credential Schema Registry — [GLEIF-vLEI-TechReq-Part3]¶

Applications that use this media type:¶

• GLEIF vLEI issuance and verification systems.¶

• SATP-compliant credential exchange platforms.¶

• Forensic credential chaining and audit systems.¶

Fragment identifier considerations:¶

• None¶

Additional information:¶

• Magic number(s): None¶

• File extension(s): .acdcjson¶

• Macintosh file type code(s): None¶

Person & email address to contact for further information:¶

• N. Smith ned.smith.ietf@outlook.com¶

• GLEIF IT Team vlei-support@gleif.org¶

Intended usage:¶

• COMMON¶

Author:¶

• N. Smith ned.smith.ietf@outlook.com¶

• GLEIF IT Team vlei-support@gleif.org¶

Change controller:¶

• IETF / GLEIF¶

8.1.2. application/cesr+cbor

Type name:¶

• application¶

Subtype name:¶

• cesr+cbor¶

Required parameters:¶

• None¶

Optional parameters:¶

• profile — Indicates the payload conforms to a specific vLEI credential type.¶

• encoding — Indicates the ACDC stream is text or binary. Defaults to cbor.¶

• charset — Indicates character set for text encodings. Defaults to UTF-8.¶

Encoding considerations:¶

• ACDC streams are CBOR encoded for use with binary transports. If the transport is a text stream the encoding option should be specified.¶

Security considerations:¶

• See Section 7.¶

Interoperability considerations:¶

None.¶

Published specification:¶

• RFCthis¶

• Key Event Receipt Infrastructure (KERI) — [KERI-Spec]¶

• Authentictic Chained Data Containers (ACDC) — [ACDC-Spec]¶

• Composable Event Streaming Representation (CESR) — [CESR-Spec]¶

• GLEIF vLEI Credential Schema Registry — [GLEIF-vLEI-TechReq-Part3]¶

Applications that use this media type:¶

• GLEIF vLEI issuance and verification systems¶

• SATP-compliant credential exchange platforms¶

• Forensic credential chaining and audit systems¶

Fragment identifier considerations:¶

• None¶

Additional information:¶

• Magic number(s): None¶

• File extension(s): .acdcbor¶

• Macintosh file type code(s): None¶

Person & email address to contact for further information:¶

• N. Smith ned.smith.ietf@outlook.com¶

• GLEIF IT Team vlei-support@gleif.org¶

Intended usage:¶

• COMMON¶

Author:¶

• N. Smith ned.smith.ietf@outlook.com¶

• GLEIF IT Team vlei-support@gleif.org¶

Change controller:¶

• IETF / GLEIF¶

8.1.3. application/cesr+msgpk

Type name:¶

• application¶

Subtype name:¶

• cesr+msgpk¶

Required parameters:¶

• None¶

Optional parameters:¶

• profile — Indicates the payload conforms to a specific vLEI credential type.¶

• encoding — Indicates the ACDC stream is text or binary. Defaults to msgpk.¶

• charset — Indicates character set for text encodings. Defaults to UTF-8.¶

Encoding considerations:¶

• ACDC streams are MSGPK encoded for use with binary transports. If the transport is a text stream the encoding option should be specified.¶

Security considerations:¶

• See Section 7.¶

Interoperability considerations:¶

None.¶

Published specification:¶

• RFCthis¶

• Key Event Receipt Infrastructure (KERI) — [KERI-Spec]¶

• Authentictic Chained Data Containers (ACDC) — [ACDC-Spec]¶

• Composable Event Streaming Representation (CESR) — [CESR-Spec]¶

• GLEIF vLEI Credential Schema Registry — [GLEIF-vLEI-TechReq-Part3]¶

Applications that use this media type:¶

• GLEIF vLEI issuance and verification systems¶

• SATP-compliant credential exchange platforms¶

• Forensic credential chaining and audit systems¶

Fragment identifier considerations:¶

• None¶

Additional information:¶

• Magic number(s): None¶

• File extension(s): .acdcmsgpk¶

• Macintosh file type code(s): None¶

Person & email address to contact for further information:¶

• N. Smith ned.smith.ietf@outlook.com¶

• GLEIF IT Team vlei-support@gleif.org¶

Intended usage:¶

• COMMON¶

Author:¶

• N. Smith ned.smith.ietf@outlook.com¶

• GLEIF IT Team vlei-support@gleif.org¶

Change controller:¶

• IETF / GLEIF¶

8.1.4. application/cesr

Type name:¶

• application¶

Subtype name:¶

• cesr¶

Required parameters:¶

• None¶

Optional parameters:¶

• profile — Indicates the payload conforms to a specific vLEI credential type.¶

• encoding — Indicates the CESR stream is text or binary. Defaults to text. encoding=binary indicates the CESR stream is binary encoded.¶

• charset — Indicates character set for text encodings. Defaults to UTF-8.¶

Encoding considerations:¶

• CESR defaults to UTF-8 text encoding and is self-framing.¶

• CESR can also be a binary stream. When used in binary mode the encoding option MUST be specified (e.g., encoding=binary).¶

Security considerations:¶

• See Section 8.¶

Interoperability considerations:¶

None.¶

Published specification:¶

• RFCthis¶

• Key Event Receipt Infrastructure (KERI) — [KERI-Spec]¶

• Authentictic Chained Data Containers (ACDC) — [ACDC-Spec]¶

• Composable Event Streaming Representation (CESR) — [CESR-Spec]¶

• GLEIF vLEI Credential Schema Registry — [GLEIF-vLEI-TechReq-Part3]¶

Applications that use this media type:¶

• GLEIF vLEI issuance and verification systems¶

• SATP-compliant credential exchange platforms¶

• Forensic credential chaining and audit systems¶

Fragment identifier considerations:¶

• None¶

Additional information:¶

• Magic number(s): None¶

• File extension(s): .acdccesr¶

• Macintosh file type code(s): None¶

Person & email address to contact for further information:¶

• N. Smith ned.smith.ietf@outlook.com¶

• GLEIF IT Team vlei-support@gleif.org¶

Intended usage:¶

• COMMON¶

Author:¶

• N. Smith ned.smith.ietf@outlook.com¶

• GLEIF IT Team vlei-support@gleif.org¶

Change controller:¶

• IETF / GLEIF¶