Session Date/Time: 15 Aug 2023 14:00

SATP

Summary

The SATP Working Group held an interim meeting on August 15th, 2023. The primary discussions revolved around updates to the architecture document, addressing specific GitHub issues raised by Yaron, and a detailed exploration of a proposal for an Asset Network Identification Identifier (ANI ID). Key technical points included the nature of trust in gateways, primary/backup gateway strategies, the scope of "Stage Zero" requirements, and the need for a globally interoperable, self-verifiable identifier for various digital asset networks. Action items were identified for further mailing list discussions and a potential follow-up subgroup call.

Key Discussion Points

Meeting Logistics & Note Well: Wes Hardiker (Chair) opened the meeting, reminded participants of the IETF Note Well, and noted the agenda.
Architecture Draft Updates:
- Thomas gave an update, stating the architecture is largely in lockstep with SATP Core, particularly regarding flows.
- He highlighted the need for specific parameters like originator and gateway owner identities (solutions like X.509/VCs exist and are out of scope for SATP directly).
- A significant gap identified was the lack of an Asset Network Identification Identifier (ANI ID), which became a central topic.
- Discussion of GitHub Issues (raised by Yaron):
  - Device Attestations: Clarified that device attestations are an optional feature, not mandatory for implementation.
  - Issue 7: Gateway Trust: Discussion focused on whether gateways are trusted by definition.
    - Rama suggested distinguishing between trust between gateways (G1 trusting G2 to be an honest person for the network behind G2) and trust by clients.
    - He also introduced the CIA (Confidentiality, Integrity, Availability) security model, suggesting networks can ensure C/I even with malicious gateways, but availability might require gateway trust.
    - Wes Hardiker noted that historical discussions hinted at legal agreements forming the basis of trust between gateways, and emphasized documenting assumptions in security considerations if certain aspects of trust are not handled by the protocol.
  - Issue 10: Primary/Backup Gateway Strategy: The question of whether N gateways implies N shadow backups or selection from the remaining N-1 was discussed.
    - Wes suggested splitting this into external aspects (DNS, load balancing, picking an IP) and internal aspects (voting mechanisms within a gateway cluster). He indicated this is better suited for mailing list discussion.
  - Stage Zero: Yaron argued that "Stage Zero" components (e.g., context ID setup, asset verification, network identification) are critical for interoperability and should be standardized within SATP's scope if they are necessary for the protocol to function. Wes clarified that any setup element required for the basic protocol to operate is no longer out of scope for the working group.
Asset Network Identification Identifier (ANI ID) Proposal:
- Thomas introduced the problem: Existing DLT network IDs (e.g., Ethereum's chain ID) often lack global interoperability and namespace consideration, leading to potential collisions.
- Proposed requirements for a global scheme: backward compatibility, support for sub-networks/forks, collision reduction without requiring a centralized authority, and self-verifiability.
- SATP's Scope for ANI ID: The diagram illustrates that SATP's concern is the identifier used between Gateway G1 and G2; how a gateway internally maps this to its network is out of SATP's scope.
- Wes reiterated SATP's blockchain-agnostic nature. He broke the identifier problem into two parts:
  1. Identifying how to connect to the remote gateway (globally understood, e.g., DNS).
  2. Identifying the specific component within the system behind the gateway (which could be a blockchain, a branch of a bank, etc.). He suggested GUID-like structures might be relevant.
- Wajia's Explanation of Self-Verifiable IDs:
  - Historically, Bitcoin had no ID, but Ethereum's 2016 fork led to EIP155 chain IDs to prevent double-spending.
  - The need is for a self-verifiable network ID, meaning a client or gateway can verify the ID's authenticity (e.g., by encoding a Genesis block hash for blockchains) to distinguish legitimate networks from "fake" ones, especially in a decentralized environment without central registration. This ID needs to be signed into transactions.
  - Wajia suggested a fixed-length (e.g., 32-byte) identifier, with the first 16 bytes potentially being a Genesis block hash, but open to customization for non-blockchain systems.
- Identifier Format Discussion:
  - Yaron suggested looking at existing chain-agnostic proposals like CAIP2, which uses a two-part identifier (namespace string + local part), allowing for extensibility and integration of existing schemes (e.g., IBAN for banking). He emphasized variable length identifiers.
  - Wajia argued for fixed-length byte-based identifiers (e.g., 32-byte) due to requirements for signing transactions and self-verification, and gas cost considerations in blockchain contexts.
  - Rama requested a precise technical definition of "self-verifiability," which Wajia elaborated as verifying against the Genesis block hash encoded in the ID.
  - Wes linked the problem to broader internet security issues of entity verification and protocol binding (e.g., Certificate Transparency), reiterating the need to document assumptions if full solutions are out of scope.
  - David pointed out that SATP's charter may require it to make assumptions about the validity of assets and networks, rather than solving all underlying trust/security problems. Wes agreed on carefully outlining what the protocol is and is not handling in security considerations.
Next Steps for ANI ID: Thomas proposed sending an email to the mailing list to gauge interest in a dedicated subgroup call for this complex identifier topic.

Decisions and Action Items

Thomas will take issues #7 (Gateway Trust) and #10 (Primary/Backup Gateway Strategy) to the mailing list to initiate further discussion.
Thomas will send an email to the mailing list proposing a date for a follow-up subgroup call specifically to discuss the Asset Network Identification Identifier (ANI ID).

Next Steps

Participants are encouraged to engage in the mailing list discussions on gateway trust and primary/backup strategies.
Look out for a proposed date for a subgroup call focused on the Asset Network Identification Identifier to continue exploring its requirements, format, and integration into SATP.
The working group will continue to evaluate "Stage Zero" elements to determine if any are essential for the core protocol's basic functionality and thus should be brought into scope.

Session Date/Time: 15 Aug 2023 14:00

SATP

Summary

Key Discussion Points

Meeting Logistics & Note Well: Wes Hardiker (Chair) opened the meeting, reminded participants of the IETF Note Well, and noted the agenda.
Architecture Draft Updates:
- Thomas gave an update, stating the architecture is largely in lockstep with SATP Core, particularly regarding flows.
- He highlighted the need for specific parameters like originator and gateway owner identities (solutions like X.509/VCs exist and are out of scope for SATP directly).
- A significant gap identified was the lack of an Asset Network Identification Identifier (ANI ID), which became a central topic.
- Discussion of GitHub Issues (raised by Yaron):
  - Device Attestations: Clarified that device attestations are an optional feature, not mandatory for implementation.
  - Issue 7: Gateway Trust: Discussion focused on whether gateways are trusted by definition.
    - Rama suggested distinguishing between trust between gateways (G1 trusting G2 to be an honest person for the network behind G2) and trust by clients.
    - He also introduced the CIA (Confidentiality, Integrity, Availability) security model, suggesting networks can ensure C/I even with malicious gateways, but availability might require gateway trust.
    - Wes Hardiker noted that historical discussions hinted at legal agreements forming the basis of trust between gateways, and emphasized documenting assumptions in security considerations if certain aspects of trust are not handled by the protocol.
  - Issue 10: Primary/Backup Gateway Strategy: The question of whether N gateways implies N shadow backups or selection from the remaining N-1 was discussed.
    - Wes suggested splitting this into external aspects (DNS, load balancing, picking an IP) and internal aspects (voting mechanisms within a gateway cluster). He indicated this is better suited for mailing list discussion.
  - Stage Zero: Yaron argued that "Stage Zero" components (e.g., context ID setup, asset verification, network identification) are critical for interoperability and should be standardized within SATP's scope if they are necessary for the protocol to function. Wes clarified that any setup element required for the basic protocol to operate is no longer out of scope for the working group.
Asset Network Identification Identifier (ANI ID) Proposal:
- Thomas introduced the problem: Existing DLT network IDs (e.g., Ethereum's chain ID) often lack global interoperability and namespace consideration, leading to potential collisions.
- Proposed requirements for a global scheme: backward compatibility, support for sub-networks/forks, collision reduction without requiring a centralized authority, and self-verifiability.
- SATP's Scope for ANI ID: The diagram illustrates that SATP's concern is the identifier used between Gateway G1 and G2; how a gateway internally maps this to its network is out of SATP's scope.
- Wes reiterated SATP's blockchain-agnostic nature. He broke the identifier problem into two parts:
  1. Identifying how to connect to the remote gateway (globally understood, e.g., DNS).
  2. Identifying the specific component within the system behind the gateway (which could be a blockchain, a branch of a bank, etc.). He suggested GUID-like structures might be relevant.
- Wajia's Explanation of Self-Verifiable IDs:
  - Historically, Bitcoin had no ID, but Ethereum's 2016 fork led to EIP155 chain IDs to prevent double-spending.
  - The need is for a self-verifiable network ID, meaning a client or gateway can verify the ID's authenticity (e.g., by encoding a Genesis block hash for blockchains) to distinguish legitimate networks from "fake" ones, especially in a decentralized environment without central registration. This ID needs to be signed into transactions.
  - Wajia suggested a fixed-length (e.g., 32-byte) identifier, with the first 16 bytes potentially being a Genesis block hash, but open to customization for non-blockchain systems.
- Identifier Format Discussion:
  - Yaron suggested looking at existing chain-agnostic proposals like CAIP2, which uses a two-part identifier (namespace string + local part), allowing for extensibility and integration of existing schemes (e.g., IBAN for banking). He emphasized variable length identifiers.
  - Wajia argued for fixed-length byte-based identifiers (e.g., 32-byte) due to requirements for signing transactions and self-verification, and gas cost considerations in blockchain contexts.
  - Rama requested a precise technical definition of "self-verifiability," which Wajia elaborated as verifying against the Genesis block hash encoded in the ID.
  - Wes linked the problem to broader internet security issues of entity verification and protocol binding (e.g., Certificate Transparency), reiterating the need to document assumptions if full solutions are out of scope.
  - David pointed out that SATP's charter may require it to make assumptions about the validity of assets and networks, rather than solving all underlying trust/security problems. Wes agreed on carefully outlining what the protocol is and is not handling in security considerations.
Next Steps for ANI ID: Thomas proposed sending an email to the mailing list to gauge interest in a dedicated subgroup call for this complex identifier topic.

Decisions and Action Items

Thomas will take issues #7 (Gateway Trust) and #10 (Primary/Backup Gateway Strategy) to the mailing list to initiate further discussion.
Thomas will send an email to the mailing list proposing a date for a follow-up subgroup call specifically to discuss the Asset Network Identification Identifier (ANI ID).

Next Steps

Participants are encouraged to engage in the mailing list discussions on gateway trust and primary/backup strategies.
Look out for a proposed date for a subgroup call focused on the Asset Network Identification Identifier to continue exploring its requirements, format, and integration into SATP.
The working group will continue to evaluate "Stage Zero" elements to determine if any are essential for the core protocol's basic functionality and thus should be brought into scope.

Session Date/Time: 15 Aug 2023 14:00

SATP

Summary

Key Discussion Points

Meeting Logistics & Note Well: Wes Hardiker (Chair) opened the meeting, reminded participants of the IETF Note Well, and noted the agenda.
Architecture Draft Updates:
- Thomas gave an update, stating the architecture is largely in lockstep with SATP Core, particularly regarding flows.
- He highlighted the need for specific parameters like originator and gateway owner identities (solutions like X.509/VCs exist and are out of scope for SATP directly).
- A significant gap identified was the lack of an Asset Network Identification Identifier (ANI ID), which became a central topic.
- Discussion of GitHub Issues (raised by Yaron):
  - Device Attestations: Clarified that device attestations are an optional feature, not mandatory for implementation.
  - Issue 7: Gateway Trust: Discussion focused on whether gateways are trusted by definition.
    - Rama suggested distinguishing between trust between gateways (G1 trusting G2 to be an honest person for the network behind G2) and trust by clients.
    - He also introduced the CIA (Confidentiality, Integrity, Availability) security model, suggesting networks can ensure C/I even with malicious gateways, but availability might require gateway trust.
    - Wes Hardiker noted that historical discussions hinted at legal agreements forming the basis of trust between gateways, and emphasized documenting assumptions in security considerations if certain aspects of trust are not handled by the protocol.
  - Issue 10: Primary/Backup Gateway Strategy: The question of whether N gateways implies N shadow backups or selection from the remaining N-1 was discussed.
    - Wes suggested splitting this into external aspects (DNS, load balancing, picking an IP) and internal aspects (voting mechanisms within a gateway cluster). He indicated this is better suited for mailing list discussion.
  - Stage Zero: Yaron argued that "Stage Zero" components (e.g., context ID setup, asset verification, network identification) are critical for interoperability and should be standardized within SATP's scope if they are necessary for the protocol to function. Wes clarified that any setup element required for the basic protocol to operate is no longer out of scope for the working group.
Asset Network Identification Identifier (ANI ID) Proposal:
- Thomas introduced the problem: Existing DLT network IDs (e.g., Ethereum's chain ID) often lack global interoperability and namespace consideration, leading to potential collisions.
- Proposed requirements for a global scheme: backward compatibility, support for sub-networks/forks, collision reduction without requiring a centralized authority, and self-verifiability.
- SATP's Scope for ANI ID: The diagram illustrates that SATP's concern is the identifier used between Gateway G1 and G2; how a gateway internally maps this to its network is out of SATP's scope.
- Wes reiterated SATP's blockchain-agnostic nature. He broke the identifier problem into two parts:
  1. Identifying how to connect to the remote gateway (globally understood, e.g., DNS).
  2. Identifying the specific component within the system behind the gateway (which could be a blockchain, a branch of a bank, etc.). He suggested GUID-like structures might be relevant.
- Wajia's Explanation of Self-Verifiable IDs:
  - Historically, Bitcoin had no ID, but Ethereum's 2016 fork led to EIP155 chain IDs to prevent double-spending.
  - The need is for a self-verifiable network ID, meaning a client or gateway can verify the ID's authenticity (e.g., by encoding a Genesis block hash for blockchains) to distinguish legitimate networks from "fake" ones, especially in a decentralized environment without central registration. This ID needs to be signed into transactions.
  - Wajia suggested a fixed-length (e.g., 32-byte) identifier, with the first 16 bytes potentially being a Genesis block hash, but open to customization for non-blockchain systems.
- Identifier Format Discussion:
  - Yaron suggested looking at existing chain-agnostic proposals like CAIP2, which uses a two-part identifier (namespace string + local part), allowing for extensibility and integration of existing schemes (e.g., IBAN for banking). He emphasized variable length identifiers.
  - Wajia argued for fixed-length byte-based identifiers (e.g., 32-byte) due to requirements for signing transactions and self-verification, and gas cost considerations in blockchain contexts.
  - Rama requested a precise technical definition of "self-verifiability," which Wajia elaborated as verifying against the Genesis block hash encoded in the ID.
  - Wes linked the problem to broader internet security issues of entity verification and protocol binding (e.g., Certificate Transparency), reiterating the need to document assumptions if full solutions are out of scope.
  - David pointed out that SATP's charter may require it to make assumptions about the validity of assets and networks, rather than solving all underlying trust/security problems. Wes agreed on carefully outlining what the protocol is and is not handling in security considerations.
Next Steps for ANI ID: Thomas proposed sending an email to the mailing list to gauge interest in a dedicated subgroup call for this complex identifier topic.

Decisions and Action Items

Thomas will take issues #7 (Gateway Trust) and #10 (Primary/Backup Gateway Strategy) to the mailing list to initiate further discussion.
Thomas will send an email to the mailing list proposing a date for a follow-up subgroup call specifically to discuss the Asset Network Identification Identifier (ANI ID).

Next Steps

Participants are encouraged to engage in the mailing list discussions on gateway trust and primary/backup strategies.
Look out for a proposed date for a subgroup call focused on the Asset Network Identification Identifier to continue exploring its requirements, format, and integration into SATP.
The working group will continue to evaluate "Stage Zero" elements to determine if any are essential for the core protocol's basic functionality and thus should be brought into scope.

Session Date/Time: 15 Aug 2023 14:00

SATP

Summary

Key Discussion Points

Meeting Logistics & Note Well: Wes Hardiker (Chair) opened the meeting, reminded participants of the IETF Note Well, and noted the agenda.
Architecture Draft Updates:
- Thomas gave an update, stating the architecture is largely in lockstep with SATP Core, particularly regarding flows.
- He highlighted the need for specific parameters like originator and gateway owner identities (solutions like X.509/VCs exist and are out of scope for SATP directly).
- A significant gap identified was the lack of an Asset Network Identification Identifier (ANI ID), which became a central topic.
- Discussion of GitHub Issues (raised by Yaron):
  - Device Attestations: Clarified that device attestations are an optional feature, not mandatory for implementation.
  - Issue 7: Gateway Trust: Discussion focused on whether gateways are trusted by definition.
    - Rama suggested distinguishing between trust between gateways (G1 trusting G2 to be an honest person for the network behind G2) and trust by clients.
    - He also introduced the CIA (Confidentiality, Integrity, Availability) security model, suggesting networks can ensure C/I even with malicious gateways, but availability might require gateway trust.
    - Wes Hardiker noted that historical discussions hinted at legal agreements forming the basis of trust between gateways, and emphasized documenting assumptions in security considerations if certain aspects of trust are not handled by the protocol.
  - Issue 10: Primary/Backup Gateway Strategy: The question of whether N gateways implies N shadow backups or selection from the remaining N-1 was discussed.
    - Wes suggested splitting this into external aspects (DNS, load balancing, picking an IP) and internal aspects (voting mechanisms within a gateway cluster). He indicated this is better suited for mailing list discussion.
  - Stage Zero: Yaron argued that "Stage Zero" components (e.g., context ID setup, asset verification, network identification) are critical for interoperability and should be standardized within SATP's scope if they are necessary for the protocol to function. Wes clarified that any setup element required for the basic protocol to operate is no longer out of scope for the working group.
Asset Network Identification Identifier (ANI ID) Proposal:
- Thomas introduced the problem: Existing DLT network IDs (e.g., Ethereum's chain ID) often lack global interoperability and namespace consideration, leading to potential collisions.
- Proposed requirements for a global scheme: backward compatibility, support for sub-networks/forks, collision reduction without requiring a centralized authority, and self-verifiability.
- SATP's Scope for ANI ID: The diagram illustrates that SATP's concern is the identifier used between Gateway G1 and G2; how a gateway internally maps this to its network is out of SATP's scope.
- Wes reiterated SATP's blockchain-agnostic nature. He broke the identifier problem into two parts:
  1. Identifying how to connect to the remote gateway (globally understood, e.g., DNS).
  2. Identifying the specific component within the system behind the gateway (which could be a blockchain, a branch of a bank, etc.). He suggested GUID-like structures might be relevant.
- Wajia's Explanation of Self-Verifiable IDs:
  - Historically, Bitcoin had no ID, but Ethereum's 2016 fork led to EIP155 chain IDs to prevent double-spending.
  - The need is for a self-verifiable network ID, meaning a client or gateway can verify the ID's authenticity (e.g., by encoding a Genesis block hash for blockchains) to distinguish legitimate networks from "fake" ones, especially in a decentralized environment without central registration. This ID needs to be signed into transactions.
  - Wajia suggested a fixed-length (e.g., 32-byte) identifier, with the first 16 bytes potentially being a Genesis block hash, but open to customization for non-blockchain systems.
- Identifier Format Discussion:
  - Yaron suggested looking at existing chain-agnostic proposals like CAIP2, which uses a two-part identifier (namespace string + local part), allowing for extensibility and integration of existing schemes (e.g., IBAN for banking). He emphasized variable length identifiers.
  - Wajia argued for fixed-length byte-based identifiers (e.g., 32-byte) due to requirements for signing transactions and self-verification, and gas cost considerations in blockchain contexts.
  - Rama requested a precise technical definition of "self-verifiability," which Wajia elaborated as verifying against the Genesis block hash encoded in the ID.
  - Wes linked the problem to broader internet security issues of entity verification and protocol binding (e.g., Certificate Transparency), reiterating the need to document assumptions if full solutions are out of scope.
  - David pointed out that SATP's charter may require it to make assumptions about the validity of assets and networks, rather than solving all underlying trust/security problems. Wes agreed on carefully outlining what the protocol is and is not handling in security considerations.
Next Steps for ANI ID: Thomas proposed sending an email to the mailing list to gauge interest in a dedicated subgroup call for this complex identifier topic.

Decisions and Action Items

Thomas will take issues #7 (Gateway Trust) and #10 (Primary/Backup Gateway Strategy) to the mailing list to initiate further discussion.
Thomas will send an email to the mailing list proposing a date for a follow-up subgroup call specifically to discuss the Asset Network Identification Identifier (ANI ID).

Next Steps

Participants are encouraged to engage in the mailing list discussions on gateway trust and primary/backup strategies.
Look out for a proposed date for a subgroup call focused on the Asset Network Identification Identifier to continue exploring its requirements, format, and integration into SATP.
The working group will continue to evaluate "Stage Zero" elements to determine if any are essential for the core protocol's basic functionality and thus should be brought into scope.

Session Date/Time: 15 Aug 2023 14:00

SATP

Summary

Key Discussion Points

Meeting Logistics & Note Well: Wes Hardiker (Chair) opened the meeting, reminded participants of the IETF Note Well, and noted the agenda.
Architecture Draft Updates:
- Thomas gave an update, stating the architecture is largely in lockstep with SATP Core, particularly regarding flows.
- He highlighted the need for specific parameters like originator and gateway owner identities (solutions like X.509/VCs exist and are out of scope for SATP directly).
- A significant gap identified was the lack of an Asset Network Identification Identifier (ANI ID), which became a central topic.
- Discussion of GitHub Issues (raised by Yaron):
  - Device Attestations: Clarified that device attestations are an optional feature, not mandatory for implementation.
  - Issue 7: Gateway Trust: Discussion focused on whether gateways are trusted by definition.
    - Rama suggested distinguishing between trust between gateways (G1 trusting G2 to be an honest person for the network behind G2) and trust by clients.
    - He also introduced the CIA (Confidentiality, Integrity, Availability) security model, suggesting networks can ensure C/I even with malicious gateways, but availability might require gateway trust.
    - Wes Hardiker noted that historical discussions hinted at legal agreements forming the basis of trust between gateways, and emphasized documenting assumptions in security considerations if certain aspects of trust are not handled by the protocol.
  - Issue 10: Primary/Backup Gateway Strategy: The question of whether N gateways implies N shadow backups or selection from the remaining N-1 was discussed.
    - Wes suggested splitting this into external aspects (DNS, load balancing, picking an IP) and internal aspects (voting mechanisms within a gateway cluster). He indicated this is better suited for mailing list discussion.
  - Stage Zero: Yaron argued that "Stage Zero" components (e.g., context ID setup, asset verification, network identification) are critical for interoperability and should be standardized within SATP's scope if they are necessary for the protocol to function. Wes clarified that any setup element required for the basic protocol to operate is no longer out of scope for the working group.
Asset Network Identification Identifier (ANI ID) Proposal:
- Thomas introduced the problem: Existing DLT network IDs (e.g., Ethereum's chain ID) often lack global interoperability and namespace consideration, leading to potential collisions.
- Proposed requirements for a global scheme: backward compatibility, support for sub-networks/forks, collision reduction without requiring a centralized authority, and self-verifiability.
- SATP's Scope for ANI ID: The diagram illustrates that SATP's concern is the identifier used between Gateway G1 and G2; how a gateway internally maps this to its network is out of SATP's scope.
- Wes reiterated SATP's blockchain-agnostic nature. He broke the identifier problem into two parts:
  1. Identifying how to connect to the remote gateway (globally understood, e.g., DNS).
  2. Identifying the specific component within the system behind the gateway (which could be a blockchain, a branch of a bank, etc.). He suggested GUID-like structures might be relevant.
- Wajia's Explanation of Self-Verifiable IDs:
  - Historically, Bitcoin had no ID, but Ethereum's 2016 fork led to EIP155 chain IDs to prevent double-spending.
  - The need is for a self-verifiable network ID, meaning a client or gateway can verify the ID's authenticity (e.g., by encoding a Genesis block hash for blockchains) to distinguish legitimate networks from "fake" ones, especially in a decentralized environment without central registration. This ID needs to be signed into transactions.
  - Wajia suggested a fixed-length (e.g., 32-byte) identifier, with the first 16 bytes potentially being a Genesis block hash, but open to customization for non-blockchain systems.
- Identifier Format Discussion:
  - Yaron suggested looking at existing chain-agnostic proposals like CAIP2, which uses a two-part identifier (namespace string + local part), allowing for extensibility and integration of existing schemes (e.g., IBAN for banking). He emphasized variable length identifiers.
  - Wajia argued for fixed-length byte-based identifiers (e.g., 32-byte) due to requirements for signing transactions and self-verification, and gas cost considerations in blockchain contexts.
  - Rama requested a precise technical definition of "self-verifiability," which Wajia elaborated as verifying against the Genesis block hash encoded in the ID.
  - Wes linked the problem to broader internet security issues of entity verification and protocol binding (e.g., Certificate Transparency), reiterating the need to document assumptions if full solutions are out of scope.
  - David pointed out that SATP's charter may require it to make assumptions about the validity of assets and networks, rather than solving all underlying trust/security problems. Wes agreed on carefully outlining what the protocol is and is not handling in security considerations.
Next Steps for ANI ID: Thomas proposed sending an email to the mailing list to gauge interest in a dedicated subgroup call for this complex identifier topic.

Decisions and Action Items

Thomas will take issues #7 (Gateway Trust) and #10 (Primary/Backup Gateway Strategy) to the mailing list to initiate further discussion.
Thomas will send an email to the mailing list proposing a date for a follow-up subgroup call specifically to discuss the Asset Network Identification Identifier (ANI ID).

Next Steps

Participants are encouraged to engage in the mailing list discussions on gateway trust and primary/backup strategies.
Look out for a proposed date for a subgroup call focused on the Asset Network Identification Identifier to continue exploring its requirements, format, and integration into SATP.
The working group will continue to evaluate "Stage Zero" elements to determine if any are essential for the core protocol's basic functionality and thus should be brought into scope.