]> Independent

ned.smith.ietf@outlook.com

Applications and Real-Time Secure Asset Transfer Protocol verifiable identities internet draft The verifiable Legal Entity Identifier (vLEI) is a cryptographically verifiable extension of the LEI standard, designed to automate trust in organizational identity. Governed by the Global Legal Entity Identifier Foundation (GLEIF), the vLEI system uses Authentic Chained Data Containers (ACDCs), Self-Addressing Identifiers (SAIDs), and Key Event Receipt Infrastructure (KERI) to issue and verify credentials for legal entities and their authorized representatives. It enables secure, machine-readable identity assertions across financial, regulatory, and supply chain ecosystems, supporting role-based delegation and interoperability with decentralized trust frameworks. This specification defines vLEI for verifiable gateway operator identities and cryptographically links the gateway operator identity to the gateway identity. Thus SATP core lock assertions are cryptographically linked to gateway operator identities. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Secure Asset Transfer Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The SATP architecture defines an interoperability architecture for interconnection between networks or systems that anticipates a secure asset transfer protocol that satisfies security, privacy, atomicity and liveliness requirements in the transfer of assets. The SATP core protocol is a protocol for exchanging digital assets that ensures the state of the asset is preserved across inter-domain transfers. It is an extensible protocol where fields containing identity and payload values that are not defined by SATP core may be defined by companion specifications. This specification defines a SATP core protocol binding for Verifiable Legal Entity Identifiers (vLEI) used to identify SATP gateways and the organizations that operate them. In some use cases, the assets being transferred have legal considerations such that officers of the organization are expected to authorize digital asset transfers. This specification details the various vLEI credentials needed and how to integrate them with SATP core messages. SATP core message binding anticipates use of a message wrapper that uses media type and content format identifiers to facilitate interoperability with vLEI and other credential types.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

• Legal Entity : any organization or structure that is legally or financially responsible for its actions and can enter into financial transactions, explicitly excluding natural persons except where they act as sole proprietors recognized as legal entities .
• Natural person : a living human being (LLI).

vLEI Identities and Credentials The SATP core protocol defines a set of entities that participate in an asset transfer. These entities are represented in differennt ways including identifiers, credentials and public keys. SATP entities are presumed to have been issued cryptographically relevant identities prior to the SATP Transfer Initiation Stage (Stage 1) and subsequent exchanges. An entity (see Section 3 that weilds a cryptographic key pair can be described as a principal . SATP Gateways and Networks as well as the key management infrastructure that authorizes these keys are all principals.

vLEI Credential Attributes A legal entity identifier (LEI) is essentially a globally unique value issued by a well-known entity trusted to manage the LEI namespace correctly. A verifiable LEI (vLEI) is an Authentic Chained Data Container (ACDC) credential that contains three attributes:

• Legal Entity Identifier (LEI)
• Person Identifier - human friendly name
• Organizational Role Identifier - defined by a namespace controller such as GLEIF .

A vLEI ACDC attributes also contain an Autonomic Identifier (AID) that identifies the principal to which the other vLEI attributes are bound. In PKIX terminology, this AID identifies the subject. A vLEI ACDC also contains an issuer AID that identifies the issuing principal. vLEI credentials are issued to non-natural person legal entities (see and ). Nevertheless, these credentials contain personLegalName and engagementContextRole attributes that are typically associated with natural persons.

KERI Key Management AIDs reference Key Event Log (KEL) events that can be verified by outside entities; as such is a form of key attestation. An ACDC issuer is anchored to a key inception event which is a digest of the current and pre-rotated keys and other key management context. The digest becomes the issuer's autonomic identifier (AID). An ACDC credential can be identified by hashing its contents. The resulting digest is called a Self-Addressing Identifier (SAID) . Periodically, key events are appended to the KEL resulting in a different key state. However, the key inception event (the first event) remains unchanged. Anchoring AIDs to inception events means the identifier is relatively long lived as even key rotation events are anticipated at inception. Key rotation events that exceed the number of pre-rotated keys results in a new key inception event that conseqently invalidates its previous AID. When applying vLEI to SATP, ACID properties suggest that the state of the exchanged asset, the protocol state, and the key state play a role in determining the overall state of the asset exchange. Ideally, SATP principals (including key state) is locked down as part of reliable asset exchange where the complete state can be rolled back to a known-good state. However, if key state can't be locked as part of a SATP asset exchange, key state verification at each SATP stage may be needed to verify the subsequent key state changes occuring during SATP stages does not present a security relevant condition.

SATP Credentialing Assumptions SATP signing keys (e.g., senderGatewaySignaturePublicKey) that are based on ACDC credentials implicitly support key attestation as part of key verification. SATP device keys (e.g., senderGatewayDeviceIdentityPubKey) used for device authentication or device attestation can furthur strengthen trustworthiness claims of SATP endpoints. Some SATP keys do not use vLEI credentals, but could still be based on ACDC credentials. Still other credential types (e.g., PKIX ) could be leveraged, but complicates key and trust management. RFCthis assumes SATP stage 1 messages that contain identifiers and public keys are artifacts of credentials that have been issued to SATP defined entities. In addition, SATP entities are authorized by vLEI hierarchy that supplies a legal context for asset exchange Nevertheless, the GatewayDeviceIdentityPublicKey could be associated with a different credential from that belonging to the GatewaySignaturePublicKey. Consequently, there MAY be additional credentials issued to SATP principals that require additional verifier processing that ensures the asset transfer legal context is in force despite bifurcated credential formats and infrastructure.

SATP Identity Binding shows SATP entities with corresponding SATP message types mapped to a suitable credential structure. Stage 1 defines uses credential artifacts (i.e., identifiers and public keys) implying credential issuance occurred earlier, possibly during Stage 0. RFCthis assumes all credentials issued are (or can be) ACDCs. The entity identifier within an ACDD is an autonomic identifer (AID), which is semantically aligned with SATP IDs. Mapping of SATP Entities and Messages to Credential Type

SATP Entity	SATP Message	Structure
Originator	OriginatorCredential -implied-	vLEI
	verifiedOriginatorEntityID	AID
	originatorPubkey	KEL or other
Sender Gateway Owner	senderGatewayOwnerCredential -implied-	vLEI
	senderGatewayOwnerID	AID
Sender Gateway (G1)	senderGatewayCredential -implied-	ACDC
	senderGatewayId	AID
	senderGatewaySignaturePublicKey	KEL or other
Sender Gateway (G1)	senderGatewayDeviceIdentityCredential -implied-	ACDC
	senderGatewayDeviceIdentityId -implied-	AID
	senderGatewayDeviceIdentityPubkey	KEL or other
Sender Network	senderNetworkCredential -implied-	ACDC
	senderGatewayNetworkId	AID
.............	.........................................	....
Beneficiary	BeneficiaryCredential -implied-	vLEI
	beneficiaryPubkey	KEL or other
	verifiedBeneficiaryEntityID	AID
Receiver Gateway Owner	receiverGatewayOwnerCredential -implied-	vLEI
	senderGatewayOwnerID	AID
Receiver Gateway (G2)	receiverGatewayCredential -implied-	ACDC
	receiverGatewayId	AID
	receiverGatewaySignaturePublicKey	KEL or other
Receiver Gateway (G2)	receiverGatewayDeviceIdentityCredential -implied-	ACDC
	receiverGatewayDeviceIdentityId -implied-	AID
	receiverGatewayDeviceIdentityPubkey	KEL or other
Recipient Network	recipientNetworkCredential -implied-	ACDC
	recipientGatewayNetworkId	AID

vLEI Roles The vLEI ecosystem defines roles-specific credentials. Version 1.0 of vLEI defines six ecosystem roles. vLEI Ecosystem Roles

vLEI Role	Abbreviation
QualifiedvLEIIssuervLEICredential	QVI
LegalEntityvLEICredential	LEID
OORAuthorizationvLEICredential	OORA
LegalEntityOfficialOrganizationalRolevLEICredential	OOR
ECRAuthorizationvLEICredential	ECRA
LegalEntityEngagementContextRolevLEICredential	ECR

The vLEI role architecdture is a hierarchical namespace. The QVI role manages the top-level namespace. It oversees the lifecycle of subordinate namespaces (e.g., LEID, OORA, and ECRA) which are also characterized as roles. The LEID role manages the LEID namespace. The OORA role manages the OORA namespace and lifecycle of its subordinate OOR role. The ECRA role manages the ECR namespace and lifecycle of its subordinate ECR role. The LEID, OOR, and ECR are non-natural person roles (see ). Non-vLEI credentials are used to identify and authenticate such entities.

vLEI Schemas The various vLEI ACDC objects conform to JSON Schemas:

• LEID.
• QVI.
• OORA.
• ECRA.
• OOR.
• ECR.

These schemas are used to validate JSON realizations of vLEI credentials. Other representations such as CBOR and message pack can be realized, but the schemas used to validate them are not available at the time of this writing.

LegalEntityEngagementContextRolevLEICredential Credentials The SATP Messages in row 3 of 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.

vLEI Binding Architecture The SATP core protocol defines several extensible protocol fields that contain identity and other values not defined by SATP core. To facilitate interoperability these fields SHOULD contain a media type or content format wrapper. This specation requests IANA assignment of media type and content format identifiers for vLEIs which are serialized as Composable Event Streaming Representation (CESR) objects in JSON and other formats. See . Note: SATP describes Gateway secure channel establishment public key-pair but this isn't represented in the list of message publickey message types. Gateway Credential type isn't used in any of the stages afaik. There should be an IANA registry for the allowed credential types (vLEI, SAML, OAuth, PKIX).

SATP vLEI Mapping The SATP protocol defines a set of SATP flows that are divided into protocol message exchange blocks called stages. The stage-1 messages are illustrated in . The SATP entity that authors the various stage-1 messages is also depicted in . The authority used to assert SATP messages is based on a cryptographic credential that is used to authenticate the message. SATP asset transfers depend on properly established organizational authority contexts. illustrates the relationships between the various SATP entities, some of which are implied, and the source of authority. The table is ordered according to an authority hierarchy with the root authority in the first row and leaf entitities on the 6th row. Authority is therefore cumulative from row to row. The type of credential used to represent authority is in column 3. Mapping SATP Entity to vLEI Role

#	SATP Entity	vLEI Type & Authority Chain	Credential Type	Notes
1	Root vLEI Issuer -implied-	GLEIF	vLEI	Root namespace authority (e.g., GLEIF)
2	Qualified vLEI Issuer -implied-	GLEIF>>QVI	vLEI	Inter organizational namespace authority
3	Organizational vLEI Issuer -implied-	QVI>>LEID	vLEI	Organizational level namespace authority
4	Originator, Beneficiary, Gateway Owner	LEID>>OORA, LEID>>ECRA, LEID>>OORA>>OOR, LEID>>ECRA>>ECR	vLEI	Person-in-role credential
5	Gateway / Network Operations Manager / Admin -implied-	ECR>>ACDC>>KEL, ECR>>KEL, ECR(as other issuer)>>other	ACDC, KEL, other	Operational credentials (not defined by vLEI)
6	Sender/Receiver Gateway, Sender/Recipient Network	n/a	KEL, other	Device or system identity

1. GLEIF is a well-known root authority in the vLEI ecosystem. The GLEIF AID is public knowledge.
2. Second tier QVI authorities are credentialed by a root authority. Typically, second tier authorities are inter-organizational issuing credentials to multiple organizational entities.
3. Orgainzational entities use an LEID credential to manage intra-organizational namespaces.
4. SATP stage-1 messages imply the existence of oganization level entities such as Originator, Beneficiary, and Gateway Owners. vLEI defines two forms of person-in-role credentials that map to these SATP entities. OOR for organizational officers and ECR for oganizational departments or functions. SATP use cases likely depend on ECR credentials. A legal entity may delegate credential issuance by naming an alternate legal entity using OOR Authority (OORA) or ECR Authority (ECRA) delegation credentials.
5. SATP architecture assumes the existence of intra-organizational entities that manage and adminster networks and servers. vLEI doesn't define such roles and SATP stage-1 messages don't explicitly mention the existence of such entities. However, the people responsible for administering and managing the systems that implement SATP message exchange have credentials that tie into the organizational accountability framework envisaged by vLEI. These credentials can be KERI based (e.g., KEL, ACDC) or other (e.g., PKIX).
6. SATP stage-1 messages describe various services and networks that have been credentialed with device or system identities. These credentials can be KERI based or other. KERI based credentials reference the key holders AID that is the identity of the gateway or network principal that weilds the corresponding private key. An PKIX device certificate associates a subject name to the public key of the gateway or network principal that weilds the corresponding private key. A SATP gateway or network can be a principal that has multiple key management subsystems (e.g., KERI and PKIX).

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 4 . 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... Note: Need to describe how this draft approaches both top-down and bottom-up protocol binding e.g., http and tls.

Key Structures Keys embedded in hardware or firmware may not easily be converted to an interoperablel format, hence support for multiple key formats ensures the SATP protocols can be implemented by a wide variety of systems. The SATP PublicKey messages SHALL be encoded using JSON Web Key (JWK) , COSE key , PKIX key in PEM or DER, or as key events . Other key formats SHOULD be allowed but are out of scope for RFCthis.

SATP Message Wrapper Schema The following CDDL defines the wrapper and application to SATP fields.

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.

vLEI Wrapper

Content References ]]>

Key Wrappers

vLEI Media Types vLEI credentials are expressed as Authentic Chained Data Containers (ACDC) . Section request IANA assignment of media types and content format identifiers . SATP core anticipates JSON encoded message. vLEI credentials can subsequently be JSON encoded while also being CESR compliant. CESR defines JSON, CBOR, MSGPK and native CESR variants. The follwing media types MAY be used when building credential payloads for SATP: vLEI media types

Media Types
application/cesr+json
application/cesr+cbor
application/cesr+msgpk
application/cesr

The media types in have start codes that comply with the media type's structured syntax suffix, but require CESR-aware parsers that can detect them. The "cesr" subtype informs parsers that they have to do start code look-ahead processing. The "cesr" subtype also informs parsers that the CESR stream may contain a variety of objects including ACDCs, AIDs, and SAIDs (as mentioned in previous sections of RFCthis).

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 . vLEI profiles

Profile name	Profile ID
QualifiedvLEIIssuervLEICredential (QVI)	profile=urn:vlei:qvi
LegalEntityvLEICredential (LEID)	profile=urn:vlei:leid
ECRAuthorizationvLEICredential (ECRA)	profile=urn:vlei:ecra
LegalEntityEngagementContextRolevLEICredential (ECR)	profile=urn:vlei:ecr
OORAuthorizationvLEICredential (OORA)	profile=urn:vlei:oora
LegalEntityOfficialOrganizationalRolevLEICredential (OOR)	profile=urn:vlei:oor

The various vLEI credential types can be specified in a media type using the profile option. 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.

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, .

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=".

Verification of vLEI Payloads TODO

Implementation Status TODO

Security Considerations The following security properties are assumed for all payloads identified by media types defined in RFCthis:

• ACDC payloads are cryptographically signed.
• CESR payloads are cryptographically signed and self-framing.
• Signature verification is required to ensure authenticity and integrity.
• Credential provenance must be anchored to a trusted root. For example, the GLEIF Root AID via ACDC edges (see ).
• vLEIs must be validated against the vLEI schema. See .

IANA Considerations

Media Type Assignment IANA is requested to add the following media types to the "Media Types" registry .

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 .

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) —
• Authentictic Chained Data Containers (ACDC) —
• Composable Event Streaming Representation (CESR) —
• GLEIF vLEI Credential Schema Registry —

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

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 .

Interoperability considerations: None. Published specification:

• RFCthis
• Key Event Receipt Infrastructure (KERI) —
• Authentictic Chained Data Containers (ACDC) —
• Composable Event Streaming Representation (CESR) —
• GLEIF vLEI Credential Schema Registry —

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

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 .

Interoperability considerations: None. Published specification:

• RFCthis
• Key Event Receipt Infrastructure (KERI) —
• Authentictic Chained Data Containers (ACDC) —
• Composable Event Streaming Representation (CESR) —
• GLEIF vLEI Credential Schema Registry —

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

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 .

Interoperability considerations: None. Published specification:

• RFCthis
• Key Event Receipt Infrastructure (KERI) —
• Authentictic Chained Data Containers (ACDC) —
• Composable Event Streaming Representation (CESR) —
• GLEIF vLEI Credential Schema Registry —

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

CoAP Content-Format ID Assignments IANA is requested to assign the following Content-Format numbers in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry : New Content-Formats

Content-Type	Content Coding	ID	Reference
application/cesr+json	-	TBA1	RFCthis
application/cesr+cbor	-	TBD2	RFCthis
application/cesr+msgpk	-	TBD3	RFCthis
application/cesr	-	TBD4	RFCthis
application/cesr+json;profile=urn:vlei:leid	-	TBA10	RFCthis
application/cesr+json;profile=urn:vlei:ecr	-	TBA11	RFCthis
application/cesr+json;profile=urn:vlei:oor	-	TBA12	RFCthis
application/cesr+json;profile=urn:vlei:oora	-	TBA13	RFCthis
application/cesr+json;profile=urn:vlei:qvi	-	TBA14	RFCthis
application/cesr+json;profile=urn:vlei:ecra	-	TBA15	RFCthis
application/cesr+cbor;profile=urn:vlei:leid	-	TBA20	RFCthis
application/cesr+cbor;profile=urn:vlei:ecr	-	TBA21	RFCthis
application/cesr+cbor;profile=urn:vlei:oor	-	TBA22	RFCthis
application/cesr+cbor;profile=urn:vlei:oora	-	TBA23	RFCthis
application/cesr+cbor;profile=urn:vlei:qvi	-	TBA24	RFCthis
application/cesr+cbor;profile=urn:vlei:ecra	-	TBA25	RFCthis
application/cesr+msgpk;profile=urn:vlei:leid	-	TBA30	RFCthis
application/cesr+msgpk;profile=urn:vlei:ecr	-	TBA31	RFCthis
application/cesr+msgpk;profile=urn:vlei:oor	-	TBA32	RFCthis
application/cesr+msgpk;profile=urn:vlei:oora	-	TBA33	RFCthis
application/cesr+msgpk;profile=urn:vlei:qvi	-	TBA34	RFCthis
application/cesr+msgpk;profile=urn:vlei:ecra	-	TBA35	RFCthis
application/cesr;profile=urn:vlei:leid	-	TBA40	RFCthis
application/cesr;profile=urn:vlei:ecr	-	TBA41	RFCthis
application/cesr;profile=urn:vlei:oor	-	TBA42	RFCthis
application/cesr;profile=urn:vlei:oora	-	TBA43	RFCthis
application/cesr;profile=urn:vlei:qvi	-	TBA44	RFCthis
application/cesr;profile=urn:vlei:ecra	-	TBA45	RFCthis

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Quant Network MIT IBM Quant Network This memo describes the Secure Asset Transfer (SAT) Protocol for digital assets. SAT is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another, each representing their corresponding digital asset networks. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit (2PC) to ensure the properties of transfer atomicity, consistency, isolation and durability. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Global Legal Entity Identifier Foundation Global Legal Entity Identifier Foundation Global Legal Entity Identifier Foundation International Organization for Standardization In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. IANA IANA Informative References MIT Quant Network Intel IBM This document proposes an interoperability architecture for the secure transfer of assets between two networks or systems based on the gateway model. International Organization for Standardization Trust Over IP Foundation Trust Over IP Foundation n.d. Trust Over IP Foundation Trust Over IP Foundation Global Legal Entity Identifier Foundation Global Legal Entity Identifier Foundation This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. International Organization for Standardization This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. MessagePack Community

Full CDDL

Examples in JSON The following SATP wrapper examples show synthetic vLEI data: The following SATP wrapper examples show synthetic key data:

Acknowledgments Nicholas Racz for review, comments, and ecosystem alignment contributions. Samuel Smith for review, comments, and KERI ACDC CESR and vLEI insights.