Concept Guides
OpenID Federation Trust Anchor

Raidiam enables Authorities and Organisations to create a Trust Framework based on the OpenID Connect Federation where Raidiam acts as a Trust Anchor.
﻿
What Federation Is
The OpenID Federation 1.0 specification outlines a mechanism that allows organisations and their technical resources, such as Identity Providers/Authorization Servers (OpenID Providers or OPs) and relying parties (RPs, i.e., applications or clients), to establish mutual trust without requiring a direct relationship. This trust is built through a trust chain, enabling the OP to accept OAuth/OIDC requests from RPs without the need for prior registration of the RP.
flowchart TB
id1[Trust Anchor - Raidiam]
id2[Organisation 1]
id3[OP - Identity Provider / Authorisation Server]
id4[Resource Server]
id5[Organisation 2]
id6[RP - client]
id7[Resource Server]
id8[OP - Identity Provider / Authorisation Server]

id1-->id2
id1-->id5
id2-->id3
id2-->id4
id5-->id6
id5-->id7
id5-->id8
flowchart TB
id1[Trust Anchor - Raidiam]
id2[Organisation 1]
id3[OP - Identity Provider / Authorisation Server]
id4[Resource Server]
id5[Organisation 2]
id6[RP - client]
id7[Resource Server]
id8[OP - Identity Provider / Authorisation Server]

id1-->id2
id1-->id5
id2-->id3
id2-->id4
id5-->id6
id5-->id7
id5-->id8
﻿
Federation participants, including identity providers, relying parties, intermediate authorities, and trust anchors, are collectively referred to as federation entities. Each federation entity is assigned a globally unique identifier known as an entity ID.
In the above diagram:
Trust Anchor: in this case, Raidiam, is an entity that represents a third party that all other parties (Organisation 1 and Organisation 2) agree to trust.
Organisation: can be represented by a number of different technical resources:
OpenID Provider (OP) -- Identity Provider / OAuth Authorisation Server
Resource Server (APIs)
Relying Party (RP) --  applications (client applications)
OPs and RPs are usually treated as Leaf Entities -- an Entity with no Subordinate Entities -- meaning there is no other entities between this entity and the Trust Anchor in the established trust hierarchy.
Trust Chain
To reflect the established trust, a Trust Chain is constructed - a sequence of Entity Statements -- JSON Web Tokens (JWTs) -- that represents the chain starting at the Leaf Entity(OP/RP) and ending in the Trust Anchor.
flowchart TB
id1[Trust Anchor - Raidiam]
id3[OP - Identity Provider / Authorisation Server]
id6[RP - client]


id3-->|Trust Chain 1|id1
id1-->|Trust Chain 1|id6
id6-->|Trust Chain 2|id1
id1-->|Trust Chain 2|id3
flowchart TB
id1[Trust Anchor - Raidiam]
id3[OP - Identity Provider / Authorisation Server]
id6[RP - client]


id3-->|Trust Chain 1|id1
id1-->|Trust Chain 1|id6
id6-->|Trust Chain 2|id1
id1-->|Trust Chain 2|id3
﻿
Entity Statements
With Raidiam used as the Trust Framework, Entity Statements are JSON Web Tokens (JWTs) issued by:
Leaf Entities (OPs/RPs): issue self-signed JWTs signed by the OPs/RPs private key.

In the example below, note that because the JWT is self-signed, both the issuer and the subject point to the Leaf Entity.
JS
{
    "iss": "Leaf Entity ID",
    "sub": "Leaf Entity ID",
    "authority_hints": [
        // Recognizes the upper Authority / Trust Anchor
        // Trust Anchor URL - Raidiam Federation
    ]

    // Other claims...
    "jwks": [
        // Leaf Entity Public Key
    ]
}
{
    "iss": "Leaf Entity ID",
    "sub": "Leaf Entity ID",
    "authority_hints": [
        // Recognizes the upper Authority / Trust Anchor
        // Trust Anchor URL - Raidiam Federation
    ]

    // Other claims...
    "jwks": [
        // Leaf Entity Public Key
    ]
}
﻿
Trust Anchor: Raidiam issues a JWT that directly authorizes the Leaf Entity terminating the Trust Chain. The JWT is signed using the Anchor's (Raidiam's) private key.
JS
{
    "iss": "Trust Anchor Entity ID - Raidiam",
    "sub": "Leaf Entity ID",

    // Other claims...
    "jwks": [
        // Trust Anchor Public Key
    ]
}
{
    "iss": "Trust Anchor Entity ID - Raidiam",
    "sub": "Leaf Entity ID",

    // Other claims...
    "jwks": [
        // Trust Anchor Public Key
    ]
}
﻿
Trust Chain Resolution
sequenceDiagram
participant rp as Relying Party
participant op as OpenID Provider
participant ta as Trust Anchor (Raidiam)
rp->>rp: Generate Entity Statement (JWT)
Note right of rp: "iss": "RP ID"
Note right of rp: "sub": "RP ID"
Note right of rp: "authority_hints":<br/> ["https://auth.sandbox.raidiam.io/"]
Note right of rp: "jwks": [RP Public Key]
rp->>rp: Self-Sign Entity Statement
Note right of rp: Sign using private key
rp->>rp: Publish self-singed JWT
Note right of rp: Must be under URL following the format:<br/> Leaf Entity Identifier (RP ID) +<br/> /.well-known/openid-federation
Note over rp, ta: All parties perform the above steps
rp->>op: Access API
op->>rp: GET Leaf Entity Identifier (RP ID) +<br/> /.well-known/openid-federation
rp->>op: Entity Configuration (Statement)
op->>op: Extract authority from Entity Configuration
Note right of op: The OP checks the RP's authority_hints<br/> for the direct authority
Note right of op: In this case, it points to Raidiam<br/>https://auth.sandbox.raidiam.io/
op->>ta: Get Trust Anchor (Raidiam) Entity Configuration (statement)<br/> https://auth.sandbox.raidiam.io/.well-known/openid-federation
Note left of ta: "iss": "https://auth.sandbox.raidiam.io/"
Note left of ta: "sub": "https://auth.sandbox.raidiam.io/"
Note left of ta: "jwks": [Raidiam public key"
Note left of ta: metadata.federation_entity.federation_fetch_endpoint
Note over op,ta: TA's Configuration is needed to know the location of the /fetch endpoint
ta->>op: Entity Configuration
op->>ta: GET /fetch?sub={RP-Entity-Configuration-SUB-Claim-Value}
ta->>op: Return JWT (Entity Statement) of the RP
Note left of ta: "iss": "TA ID"
Note left of ta: "sub": "RP ID"
Note left of ta: "jwks": "TA's public key"
Note left of ta: Signed using TA's private key
Note over op, ta: JWT indicates the Trust Anchor authorizes the RP and the OP can Trust the RA
sequenceDiagram
participant rp as Relying Party
participant op as OpenID Provider
participant ta as Trust Anchor (Raidiam)
rp->>rp: Generate Entity Statement (JWT)
Note right of rp: "iss": "RP ID"
Note right of rp: "sub": "RP ID"
Note right of rp: "authority_hints":<br/> ["https://auth.sandbox.raidiam.io/"]
Note right of rp: "jwks": [RP Public Key]
rp->>rp: Self-Sign Entity Statement
Note right of rp: Sign using private key
rp->>rp: Publish self-singed JWT
Note right of rp: Must be under URL following the format:<br/> Leaf Entity Identifier (RP ID) +<br/> /.well-known/openid-federation
Note over rp, ta: All parties perform the above steps
rp->>op: Access API
op->>rp: GET Leaf Entity Identifier (RP ID) +<br/> /.well-known/openid-federation
rp->>op: Entity Configuration (Statement)
op->>op: Extract authority from Entity Configuration
Note right of op: The OP checks the RP's authority_hints<br/> for the direct authority
Note right of op: In this case, it points to Raidiam<br/>https://auth.sandbox.raidiam.io/
op->>ta: Get Trust Anchor (Raidiam) Entity Configuration (statement)<br/> https://auth.sandbox.raidiam.io/.well-known/openid-federation
Note left of ta: "iss": "https://auth.sandbox.raidiam.io/"
Note left of ta: "sub": "https://auth.sandbox.raidiam.io/"
Note left of ta: "jwks": [Raidiam public key"
Note left of ta: metadata.federation_entity.federation_fetch_endpoint
Note over op,ta: TA's Configuration is needed to know the location of the /fetch endpoint
ta->>op: Entity Configuration
op->>ta: GET /fetch?sub={RP-Entity-Configuration-SUB-Claim-Value}
ta->>op: Return JWT (Entity Statement) of the RP
Note left of ta: "iss": "TA ID"
Note left of ta: "sub": "RP ID"
Note left of ta: "jwks": "TA's public key"
Note left of ta: Signed using TA's private key
Note over op, ta: JWT indicates the Trust Anchor authorizes the RP and the OP can Trust the RA
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
﻿
Trust Framework Types
Centralized Directory