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

Identities 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 bound to a cryptographic key is also known as a principal . A legal entity is defined by section 1 (scope). vLEIs use Autonomic Identifiers (AID) to name legal entities and to bind cryptographic keys, to form vLEI principals. AIDs are contained within an Authentic Chained Data Contain (ACDC) credential. AIDs link to Key Event Logs (KEL) that are form of key attestation. KELs change periodically as key event receipts are added to the log, thus key state could have security implications. The state of the vLEI credential may change between SATP stages or whenever a key is used. The state of an ACDC is locked to keystate at issuance. A cryptographic hash of an ACDC credential and its initial key state can be referenced using a Self-Addressing Identifier (SAID) . 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 during asset exchange. Ideally, SATP principals (including key state) are unchanging during complete asset exchange (or full rollback). However, if key-state can't be locked as part of a SATP ACID exchange, key state verification at each SATP stage may be needed. 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., X.509 )) could be used for non-natural person entities. Nevertheless, use of a Key Event Recipt Infrastructure (KERI) key means these keys can benefit from KEL-based key attestation. RFCthis assumes SATP identifiers and public keys are artifacts of a credential issued to a common entity. Nevertheless, the GatewayDeviceIdentityPublicKey could be associated with a different credential from the one belongin to the GatewaySignaturePublicKey. Consequently, there MAY be additional credentials issued to SATP principals that require additional verifier processing. Note1: Need to check if there is a KERI key encoding other than CESR and if ACDC is sufficient to describe the key.

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-	ACDC
	originatorPubkey	ACDC or other
	verifiedOriginatorEntityID	AID
Sender Gateway Owner	senderGatewayOwnerCredential -implied-	ACDC
	senderGatewayOwnerID	AID
Sender Gateway (G1)	senderGatewayCredential -implied-	ACDC
	senderGatewaySignaturePublicKey	ACDC or other
	senderGatewayId	AID
	senderGatewayDeviceIdentityCredential -implied-	ACDC
	senderGatewayDeviceIdentityPubkey	ACDC or other
	senderGatewayDeviceIdentityId -implied-	AID
Sender Network	senderNetworkCredential -implied-	ACDC
	senderGatewayNetworkId	AID
.............	.........................................	....
Beneficiary	BeneficiaryCredential -implied-	ACDC
	beneficiaryPubkey	ACDC or other
	verifiedBeneficiaryEntityID	AID
Receiver Gateway Owner	receiverGatewayOwnerCredential -implied-	ACDC
	senderGatewayOwnerID	AID
Receiver Gateway (G2)	receiverGatewayCredential -implied-	ACDC
	receiverGatewaySignaturePublicKey	ACDC or other
	receiverGatewayId	AID
	receiverGatewayDeviceIdentityCredential -implied-	ACDC
	receiverGatewayDeviceIdentityPubkey	ACDC or other
	receiverGatewayDeviceIdentityId -implied-	AID
Recipient Network	recipientNetworkCredential -implied-	ACDC
	recipientGatewayNetworkId	AID

Note2: Need to describe how this draft approaches protocol binding where focus is on top-down, but not ignoring buttom up eg tls.

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

vLEI defines a role architecdture that is hierarchical. A QVI role oversees lifecycle of LEID, OORA, and ECRA roles. The OORA role oversees lifecycle of OOR roles and the ECRA role oversees the lifecycle of ECR roles. The LEID, OOR, and ECR roles could oversee lifecycle of non-vLEI credentials; which are classified as non-natural person credentials by .

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 . Note3: 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, X.509).

SATP vLEI Mapping The SATP protocol defines a set of SATP flows that are divided into stages. maps SATP entities to specific vLEI roles. Mapping SATP Entity to vLEI Role

#	SATP Entity	vLEI Role
1	Originator, Beneficiary, Gateway Owner	LEID
2	GatewaySignature, GatewayNetwork, GatewayDeviceIdentity	non-natural person credential
3	Gateway Admin, Network Admin, Gateway Operations Manager, Network Operations Manager	ECR

Note4: The various xxxID messages are tstr values - the stringified representation of the vLEI credential identifer should be used here. This is probably an SAID. For a SATP-JSON binding, the SAID MUST use the text form of the CESR derivation code. For a SATP-CBOR or other binary binding the SAID MUST use the binary form of the CESR derivation code.

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

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.

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

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 ACDC credentials. 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:lar	-	TBA13	RFCthis
application/cesr+json;profile=urn:vlei:qvi	-	TBA14	RFCthis
application/cesr+json;profile=urn:vlei:vra	-	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:lar	-	TBA23	RFCthis
application/cesr+cbor;profile=urn:vlei:qvi	-	TBA24	RFCthis
application/cesr+cbor;profile=urn:vlei:vra	-	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:lar	-	TBA33	RFCthis
application/cesr+msgpk;profile=urn:vlei:qvr	-	TBA34	RFCthis
application/cesr+msgpk;profile=urn:vlei:vra	-	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:lar	-	TBA43	RFCthis
application/cesr;profile=urn:vlei:qvr	-	TBA44	RFCthis
application/cesr;profile=urn:vlei:vra	-	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 Trust Over IP 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]

Full CDDL = (M) .and ({ + any => any }) 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 } wrapped-vlei = { content: content-ref payload: bstr / tstr } 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" }> 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 } vlei-media-type = "application/cesr+json;profile=urn:vlei:leid" / "application/cesr+json;profile=urn:vlei:ecr" / "application/cesr+json;profile=urn:vlei:ecr;charset=utf-16le" / "application/cesr+json;profile=urn:vlei:oor" / "application/cesr+json;profile=urn:vlei:ecra" / "application/cesr+json;profile=urn:vlei:qvi" / "application/cesr+json;profile=urn:vlei:oora" / "application/cesr+json;profile=urn:vlei:oora;encoding=base64uri" / "application/cesr+cbor;profile=urn:vlei:leid" / "application/cesr+cbor;profile=urn:vlei:leid;encoding=text" / "application/cesr+cbor;profile=urn:vlei:ecr" / "application/cesr+cbor;profile=urn:vlei:ecr;encoding=base64uri" / "application/cesr+cbor;profile=urn:vlei:ecr;encoding=text" / "application/cesr+cbor;profile=urn:vlei:oor" / "application/cesr+cbor;profile=urn:vlei:oor;encoding=text" / "application/cesr+cbor;profile=urn:vlei:ecra" / "application/cesr+cbor;profile=urn:vlei:ecra;encoding=text" / "application/cesr+cbor;profile=urn:vlei:qvi" / "application/cesr+cbor;profile=urn:vlei:qvi;encoding=text" / "application/cesr+cbor;profile=urn:vlei:oora" / "application/cesr+cbor;profile=urn:vlei:oora;encoding=text" / "application/cesr+msgpk;profile=urn:vlei:leid" / "application/cesr+msgpk;profile=urn:vlei:leid;encoding=text" / "application/cesr+msgpk;profile=urn:vlei:ecr" / "application/cesr+msgpk;profile=urn:vlei:ecr;encoding=text" / "application/cesr+msgpk;profile=urn:vlei:oor" / "application/cesr+msgpk;profile=urn:vlei:oor;encoding=text" / "application/cesr+msgpk;profile=urn:vlei:ecra" / "application/cesr+msgpk;profile=urn:vlei:ecra;encoding=text" / "application/cesr+msgpk;profile=urn:vlei:qvi" / "application/cesr+msgpk;profile=urn:vlei:qvi;encoding=text" / "application/cesr+msgpk;profile=urn:vlei:oora" / "application/cesr+msgpk;profile=urn:vlei:oora;encoding=text" / "application/cesr;profile=urn:vlei:leid" / "application/cesr;profile=urn:vlei:leid;encoding=binary" / "application/cesr;profile=urn:vlei:leid;encoding=base64uri" / "application/cesr;profile=urn:vlei:leid;charset=utf-16le" / "application/cesr;profile=urn:vlei:ecr" / "application/cesr;profile=urn:vlei:ecr;encoding=binary" / "application/cesr;profile=urn:vlei:oor" / "application/cesr;profile=urn:vlei:oor;encoding=binary" / "application/cesr;profile=urn:vlei:ecra" / "application/cesr;profile=urn:vlei:ecra;encoding=binary" / "application/cesr;profile=urn:vlei:qvi" / "application/cesr;profile=urn:vlei:qvi;bencoding=binary" / "application/cesr;profile=urn:vlei:oora" / "application/cesr;profile=urn:vlei:oora;encoding=binary" ]]>

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

Acknowledgments TODO acknowledge.