OpenID Federation 1.0
Shaping The Advanced Infrastructure of Trust

18th FIM4R Workshop, 30 Jan 2024, Copenhagen

Giuseppe De Marco <demarcog83@gmail.com>
Mike Jones <michael_b_jones@hotmail.com>
John Bradley, Yubico <jbradley@yubico.com>
Roland Hedberg <roland@catalogix.se>

TODAY WE TALK ABOUT OPENID FEDERATION 1.0 WITH …

●I’m Giuseppe De Marco,●

I work as Open Source Project Leader andDigital Identity Expert for the Department for digitaltransformation of the Italian Government,●I have concrete experiences with LDAP, SAML2, OAuth 2.0
and OpenID Connect as Software Developer.

●I have designed the Italian infrastructure of trust for
OpenID Connect based on OpenID Federation 1.0, withcolleagues of other Italian institutions (AgID, IPZS) andcontributing to IETF and OpenID specifications.

●I love to work with Roland Hedberg, Mike Jones, Vladimir
Dzhuvinov, and John Bradley!

TODAY WE TALK ABOUT OPENID FEDERATION 1.0

The Technology to Build●●

An Infrastructure of Trust:○

Public and Transparent;○

Hierarchical and Decentralized … That scales!

Verifiable Digital Trust Relationships between the participants of a digital ecosystem:○not repudiable over time (even when cryptographic keys changes!).

WE ESTABLISH THE TRUST WITH SIMPLE RULES

Equation for a Relationship
PROOF of IDENTITY+PROOF of COMPLIANCE to requirements=TRUST
Periodically renewed,
like human relationships!

https://identitadigitale.gov.it/

Picture by best5.it

TRUST AS AN EMPIRICAL PROOF OF COMPLIANCE

This isanApple ..

We Need to Periodically Evaluate
The party which we are interacting with

IDENTITY

The shared terms, conditions and rules.

COMPLIANCE

Identity, alone (DNS+TLS), is not enough.
https://identitadigitale.gov.it/

What could
possibly gowrong?

WHAT SHOULDN'T HAPPEN THAT OFTEN HAPPENS

What If Something Goes Wrong?
What if Someone Cheats?
Requirement of automated policy.
Policy application MUST be enforced in a coercive manner.
HOW to do automatically this?
OpenID Federation has a Policy Language.
https://identitadigitale.gov.it/

THE NEVER ENDING LIST OF WHAT SHOULDN'T HAPPEN THAT OFTEN HAPPENS

Imagine an Ecosystem without automatic Policies evaluations …
●●●
●
●
●

The compromised/malicious RP requests User personal information through social engineering.
Fake promises, fake prizes, phishing...
The bogus Issuer issues Credentials for which it is not authorized to issue
An RP would not know which Credential Issuer is eligible for issuing determined Credentials
An RP would obtain data from under-age Users without grants for that
A fake Accreditation Body would carry out onboarding systems and inspections without any
authorization
The coffee machine that requires personal data … Do we have enough?

Never tickle your adversary's imagination!

ROLES IN THE EID ECOSYSTEMSTRUSTUSERsVC ISSUERs
Issue Digital Credentials

IDentity Providers
WALLET
Release ID Tokens
orSAML2 Responses
Authorization Servers
Release Access Tokens

VC VERIFIERs
WALLET

Proximity
Service Providers

Relying Party
Remote Service Providers

Wallet Providers
Release Wallet Mobile App

TRANSITIVE TRUST

How to go from Marco to Bob?
TRUST ANCHOR

Alice (Trust Anchor)
Bob (Intermediate)
Marco (RP)

Problems to solve:
1.
2.
3.

Arianna (IDP)

ACCREDITATION BODIES
LEAF NODES: RP, OP, RS, AS,VCI, …

How to link entities that don’t have any direct link?
How to establish if Marco and Alice comply with the same rules?
How to ensure that Marco and Bob apply Alice's rules?

THE TOPOLOGIES OF TRUST INFRASTRUCTURES

Flat vs. Decentralized and Hierarchical
Trust Anchor X

AS

INT A
RS / VCIINT B

Trust Anchor Y
INT C

RP

WalletProvider

TRUST
LISTS

WalletProviderIssuer
WALLETPROVIDER

INT D

other
LEAFNODES

IssuerVerifier

RP
Photo by freepik

Decentralized and HierarchicalReal World Example With Domains
Trust Anchor X
ORG A

ORG B

Trust Anchor Y.EDU| .IT | .UK | .JP | .FI | …

ORG C(Accreditation) Intermediates

ORG D

WalletProviderIdentity
ProviderVC Issuer
IDP B
Wallet A

RP C

Leaves (per Protocol/Role)VC Issuer C

How Wallet A can trust VC Issuer C?
Photo by freepik
How the RP C can trust IDP B?
-> They shares common rules under a Trust Anchor

REQUIREMENTS FOR LARGE SCALE AND DYNAMIC DEPLOYMENTS

Trust that scales
In small-scale and static deployments,
it’s possible to keep a list of the trusted
participants and their metadata
However, in large-scale and dynamicdeployments, that doesn’t scaleThis needs multilateral relationships,
rather than bilateral

https://identitadigitale.gov.it/

Public domain picture: Dreamstime.com

TODAY WE TALK ABOUT OPENID FEDERATION 1.0 WITH …

●

I’m Roland Hedberg,●

Author of pysaml2, SATOSA, pyoidc, idpy-oidc, fedservice,idpy-sdjwt, openid4v, satosa-openid4vci, ….

●

Started with X.500 1988. Since then mainly done LDAP,SAML2 and OIDC/OAuth2.

●Authored the OpenID Connect certification software.

How it all began …
First official occurence - IIW 21 October 2015
● Allow for semi-static client registration● Allow for off-line verification of ’documents’that are sent around.
First presentation, TNC16, Prague● Trust fabric● Endforced metadata policies● Independence of transport security● New member without bringing in the FO

https://identitadigitale.gov.it/

Public domain picture: Dreamstime.com

ROLANDROLAND
Federation roles
Trust anchor definition

https://identitadigitale.gov.it/

Public domain picture: Dreamstime.com

ROLAND

Basic Components
Signed Statements
Entity Configuration
Subordinate Statement (+ how torevoke a participant)https://identitadigitale.gov.it/

Public domain picture: Dreamstime.com

FEDERATION ENTITY DISCOVERY
serves public keys
and policies
serves public keys
and policies

authority hint
self signed

self signed

EntityConfiguration
self issued by
Leaf

EntityConfiguration
self issued byIntermediate

Entity Statement
related to the leaf
issued byIntermediateauthority hint

Entity Statement
related to its
Intermediate
issued by TrustAnchor

self signed

EntityConfiguration
published by
Trust Anchor

THE OUTCOME OF THE DISCOVERY IS THE TRUST CHAIN

Trust Anchor

Trust Chain
Intermediate

1.
Leaf

Will/how-doyou trust thisLeaf?

Photo by freepikTODAY WE TALK ABOUT OPENID FEDERATION 1.0 WITH …

●I’m Mike Jones●An independent consultant in identity and security space○ https://self-issued.consulting/
Mission: Building the Internet’s missing identity layer●●●An author of many specs that actually get used, including
OpenID Connect, JSON Web Token (JWT), multiple OAuth
specs, WebAuthn/FIDO2Working on adding OpenID Federation to that set!

SUMMARY OF THE TRUST MODEL “MUST HAVES”

REQUIREMENTS SATISFIED
1.

Are they who they say they are? (ENTITY IDENTIFIERS)

2.

Are they compliant with the security and privacy requirements
required by the ecosystem (e.g., EUDI Wallet)? (COMPLIANCE)

3.

Superiors sign statements about Subordinates in Trust Chain (KEYHIERARCHY)

4.

Authorization to carry out intended actions (POLICIES)
a. in both online & offline interactions (ENCAPSULATED TRUST)
b. and verifiable in the future using retained historical keys
(NON-REPUDIATION)
Use with any AuthN/AuthZ technology (PROTOCOL AGNOSTIC)

5.

Photo by freepik

OpenID Federation Functional Features
Flexibility● Support for protocol-specific metadata, policies, Trust Marks, and ecosystem roles. Tailored configurations meet
specific needs, enhancing adaptability in diverse environments.
● Multiple federations. Entities can participate in multiple federations with different Trust Anchors.
● Multiple roles: Can a Trust Anchor in one Federation be an intermediate in another? With OpenID Federation YES.
Transparency, online access to all Trust relationships:● Federation API makes Trust relationships transparent and consultable online by providing a standardized way toshare and access trust information, enabling real-time navigation of the federation
Dynamic Relationships among Entities● Adding entities to and removing entities from organizations and federations is a local operation● Only requires superior to issue an updated Subordinate Statement about entity (or to stop issuing it)● Short entity statement timeouts can enable timely addition, revocation, and metadata updates
Constraints ensure compliance with policies● Can prevent malicious parties and misconfigurations from performing actions they’re ineligible for
Offline Usage enabled through cached trust chains● trust_chain JWS header parameter can occur within requests, responses, attestations, and digital credentials

TODAY WE TALK ABOUT OPENID FEDERATION 1.0 WITH

●I’m John Bradley●Sr. Distinguished Architect at Yubico●A co-author of many specs,
including OpenID Connect,
JSON Web Token (JWT), multiple OAuth specs,
WebAuthn/FIDO2●

I started in 1987 with x.25, LDAP and Certificate
Authorities in 1995. Moving to SAML, InfoCard, andOpenID in 2005

Can We do all these Things with an X.509 PKI?
●●

Multilateral Federation Multiple roots of trust for a single entity?
○Requires PKI Bridges and cross signing.

○Support for validation requires special software.

Delegation?
○●In a limited way, but not in use in actual software.

Revocation?
○Requires CRL or OCSP (doesn't scale)

Photo by freepik

X.509 vs. OpenID Federation
X.509

OpenID FederationBorn

1988

2016

Format

ASN.1/DER

JWT

RESTful API–Yes

Revocations

CRL, OCSP

Using the RESTful API

Attestation artifact

Public key certificate

Entity Statement (ES)

Attestation content

1 Identity (FQDN)
1 Public Key

1 Identity (FQDN)N Public Keys
Protocol specific capabilities
GrantsChain name

Certificate chain

Trust Chain

Chain payload

Identity, Public key, constraints, custom extensions.

Identity, Public keyS, constraints, protocol
specific metadata, Trust Marks, policies,
X.509 certificates.

Cryptographic Keys specialized per scope–Federation Keys!=Protocol specific keys

Photo by freepik

Concluding

MIKE
RECAP, VISION, MILESTONES, STATUS

https://identitadigitale.gov.it/

Public domain picture: Dreamstime.com

Frequently Asked Questions
What is the status of OpenID Federation?
Core components have been stable since draft 20 (now at draft 32). Useful (optional) backwards-compatible features
added. Last Implementer’s Draft is imminent. Final specification anticipated for later this year.
Testing and Certification
Test plans critical to mitigate the risk of misconfigurations and bugs in large-scale deployments. In Italy, test plans
were applied to the production deployments.
General-purpose federation test plans and certification criteria by OpenID Foundation planned for mid-year.
Is OpenID Federation a PKI?
It’s more than a PKI, incorporating dynamic multilateral trust establishment and policy evaluation mechanisms.
Availability of Libraries and Support
Java Nimbus OAuth 2.0 SDK. Italian implementations in: Java, Python, JS, PHP, .NET (github.com/italia). Roland
Hedberg’s Python impl (https://github.com/rohe/fedservice). Ongoing work in the Research and Scholarshipcommunity, using GoLang. All Open Source.
What are the incentives for supporting both X.509 and OpenID Federation?
X.509 certificates can be used for their traditional purpose of establishing a basic level of trust based on the certificate
chain, while OpenID Federation can handle the more advanced trust management tasks, using Trust Marks andautomatic policy processing. The Federation API can be used to check the revocation of X.509 certificates within
Federation Trust Chains, without requiring OCSP and CRL lists.
Can Federation be used with ISO/IEC 18013-5?
A federation Trust Chain can be added to the COSE_Sign1 Document (MSO). This paves the way for standardization.
The Federation API can provide an equivalence of the “Verified Issuer Certificate Authority List” (VICAL).

Photo by Farah from Burst

Q&AThank You For Your Attention!
For further clarifications, ideas, proposals, or discussions, contact us●

Our e-mail addresses are on the first slide

Other recent OpenID Federation presentations:
●
●
●
●
●

Discover the Italian Federation, TNC 2022 by Roland Hedberg
How Do You Know Who to Trust?, EIC 2023 by Mike Jones
Do you Trust the Wallet?, FBK Trust and Identity Summit byFrancesco Marino (IPZS)The Key is Not Enough, OAuth Security Workshop 2023 by Vladimir
DzhuvinoveIDAS Expert Group - EUDI Wallet with OpenID Federation 1.0