OpenID Federation defines two client registration flows that replace OAuth's static client registration with dynamic, trust-chain-verified registration. **Automatic Registration**: 1. RP includes `trust_chain` header in authentication request 2. OP validates the trust chain, extracts resolved RP metadata 3. OP auto-registers the RP inline (no prior registration step) 4. OP returns authentication response with its own `trust_chain` header No pre-coordination required between RP and OP. **Explicit Registration**: 1. RP POSTs signed Entity Statement to `federation_registration_endpoint` 2. OP validates statement and trust chain 3. OP may present registration details to user for consent 4. OP issues signed Entity Statement response 5. RP uses returned `client_id` + `private_key_jwt` for subsequent requests Enables user-visible consent and persistent client identity. **Trade-offs**: Automatic is zero-friction for federation members but provides no user-visible consent step. Explicit is heavier but supports audit trails and human-in-the-loop confirmation. **Cross-domain applications**: - **API marketplaces**: Same implicit vs. explicit authorization split in OAuth scopes/consent screens - **Service mesh mutual TLS**: mTLS certificate exchange is analogous implicit trust establishment - **Enterprise app stores**: Automatic = sideloading; explicit = managed deployment with approval gate - **Human-Centered Access Control**: [[Human-Centered Access Control via Vouching]] — zero-friction vs. minimal human interaction boundaries - **Automation Trade-offs**: [[Automation Shifts Bottleneck to Design]] — automatic flow eliminates friction but shifts burden to system design - **Implicit Trust Risks**: [[Pipelines Implicitly Trust Their Inputs]] — automatic trust carries security risks requiring explicit verification - **Attention Economics**: [[Attention as Currency]] — zero-friction consumption vs. deliberate allocation parallels --- *Source: [[OpenID Federation 1.0]]*