fix: clarified multiple TA's and added definition of trust anchor list

architecture.md

@@ -5,7 +5,7 @@ This chapter describes the basic architecture of an FSC system.
 ## Identity and Trust  {#trustanchor}
 
 Connections between Managers, Inways, Outways use Mutual Transport Layer Security (mTLS) with X.509 certificates. 
-Components in the Group are configured to accept the same (Sub-) Certificate Authorities (CA) as Trust Anchors (TA). Each TA is a Trusted Third Party that ensures the identity of the Peers by verifying a set of fields of the subject field , [section 4.1.2.6](https://rfc-editor.org/rfc/rfc5280) of [[RFC5279]] that act as [PeerID](#peer_id) in each X.509 certificate.
+Components in the Group are configured to accept the same (Sub-) Certificate Authorities (CA) as defined in the Trust Anchors list (TA). Each TA is a Trusted Third Party that ensures the identity of the Peers by verifying a set of fields of the subject field , [section 4.1.2.6](https://rfc-editor.org/rfc/rfc5280) of [[RFC5279]] that act as [PeerID](#peer_id) in each X.509 certificate.
 When multiple TAs are used the TAs must ensure that the elements of the subject field used to identify a Peer are the same across the TAs. 
 
 ![mTLS Connections](diagrams/seq-mtls-connections.svg "mTLS Connections")

introduction.md

@@ -74,6 +74,11 @@ An HTTP API offered to the Group.
 
 The Trust Anchor (TA) is an authoritative entity for which trust is assumed and not derived. In the case of FSC, which uses an X.509 architecture, it is the root certificate from which the whole chain of trust is derived.
 
+*Trust Anchor List:*
+
+A list of one or more Trust Anchors. In the case of FSC, which uses an X.509 architecture, it is a list of all root certificates that are used as Trust Anchor. In practice this would be a list of one or more [Certificate Authorities](https://en.wikipedia.org/wiki/Certificate_authority) (CA's).
+Certificates issued by a CA that acts as a Trust Anchor are trusted within FSC Group.
+
 *Profile:* 
 
 A set of rules providing further restrictions and governance of the FSC Group. A Profile aligns on certain required parameters needed for the practical workings of an FSC Group. 
@@ -113,7 +118,7 @@ For example, it may be needed for an Group to have additional restrictions or ag
 A Group **MAY** use multiple Profiles to further enhance the rules and restrictions within the Group. It is the responsibility of the Group to prevent conflicts between the Profiles used by the Group.
 
 The following decisions **MUST** be part of the Profile:
-1. Select a [Trust Anchor](#trust_anchor)
+1. Select one or more [Trust Anchors](#trust_anchor) to include in the Trust Anchor list
 2. Select a [Group ID](#group_id)
 3. Select what determines the [Peer ID](#peer_id)
 4. Select what determines the [Peer name](#peer_name)

specifications.md

@@ -37,9 +37,9 @@ Each Peer **MUST** have a human-readable name which can be used to identify a Pe
 
 The Trust Anchor (TA) is an authoritative entity for which trust is assumed and not derived. In the case of FSC, which uses an X.509 architecture, it is the root certificate from which the whole chain of trust is derived.
 
-Each Group can have multiple TAs.
+Each Group can have multiple TAs that are defined in a Trust Anchor List.
 
-Every Peer in a Group **MUST** accept the same TA(s).
+Every Peer in a Group **MUST** accept the same TA(s) that are defined in the Trust Anchor List defined by the Group.
 
 The TA **SHOULD** validate a Peers identity, i.e. the TA **MUST** preform Organization Validation.