The Architecture and Protocol Flows of Trust Router
There are typically two distinct sets of keys needed in a Trust Router-based ecosystem that Trust Router is used to negotiate - a shared key between the RP and IdP that allows those two Moonshot entities to communicate, and the shared key between the IdP and APC that is used to facilitate the generation of the first key (as it allows the IdP and APC to mutual authenticate). Thus, there are three possible scenarios for Trust Router (in order of increasing complexity) - one where both keys are already established, one where only the latter key is already established, and one where neither keys are yet established. Follow the links below to see the full protocol flow for each of these three cases.
Both keys already exist
- When the RP and IdP already share a key, the flow is the simplest:Â Trust Router Protocol Flows with Existing RP/IdP Key
One key already exists
- When the RP and IdP don't share a key, but the APC and IdP do, there is a simpler, non-recursive flow:Â Trust Router Protocol Flows with Existing APC/IdP Key
No keys exist
- When nothing shares any keys, the flow is the most complex since it recurses:Â Trust Router Protocol Flows with No Established Keys