Talks & Tutorials Tuesday

Why the Trust Model of OIDC is broken

Petteri Ihalainen, Petri Suvila

Have you heard the news? The Internet is insecure! Who would've thought? Did you also know that (TLS) certs != authentication? Establishing trust is a tricky process. Who to trust? Well... the answer is as always "it depends". CAs might be an option, but there's a problem. A cert only proves that a particular (legal) entity existed at the time of issuance. Trust that the applications (relying parties in ancient talk) have good intentions and allow for dynamic registrations?

Let's take a look at what Finland had to do in order to facilitate the identity issuers, brokers and application providers to first establish trust in a tightly regulated environment, and then allow for normal OIDC operations to start. Take some core, tighten it a bit and sprinkle it with some federation. First hand experiences as the due date for complying to our regulations is June the first. And why we think there's something missing in the Trust Model.

Full Disclosure: behind the scenes of SD-JWT

Brian Campbell

The true story of the prospective IETF RFC, "Selective Disclosure for JWTs (SD-JWT)" will be presented by the last-added co-author of the draft. We'll discuss what exactly SD-JWT is and the technical details of how it works. We'll look at the origin story of the work and contemplate some of the broader implications it might have going forward.

End-to-End User Authentication with OpenID Connect: Use Cases and Benefits

Jonas Primbs

This talk presents an OpenID Connect extension for Identity Certification Tokens (ICTs). ICTs are signed by an Open ID Provider (OP) and certify that a public key belongs to a specific OIDC user. ICTs are lightweight certificates, i.e., they are short-lived and require no certificate revocation list (CRL). A user may request an ICT from its OP and use it for authentication purposes. If communication partners apply that paradigm and trust each other’s OPs, they can authenticate each other. While the original idea has been presented at OSW 2022 under the name “Message-Layer Authentication with OpenID Connect”, this talk gives an update on further developments including ease of use, use cases, prototypes, and comparison with related technologies.

To leverage this technology, the user simply logs in to his OP and requests an ICT for a public key. The OP then verifies the user’s possession of the related private key and issues an ID Certification Token (ICT). To prove his identity, the user shares his ICT with his communication partner. If the partner trusts the OP of the user, the partner verifies that the ICT is valid and authenticates the user using a challenges-response protocol.

The approach is easy to use as it does not require any pre-installed certificates for users and no CRLs for OPs. It may be applied, e.g., to video communication, instant messaging, or emails. The validity period of the ICT may be determined by the application.

We compare ICTs with similar approaches, e.g., X.509-based user certificates or SSI-based methods which mainly differ in usage and the fact that they require long-term keys. The latter implies a more heavy-weight infrastructure.

Attendees can expect to gain a comprehensive understanding of the proposed OpenID Connect extension, its practical implementation, and its unique advantages and disadvantages. The talk aims to foster engaging discussions, encourage collaboration, and drive the adoption of this innovative approach for mutual end-user authentication.

AM coffee break

Defending Against Cross-Device Consent Phishing Attacks

Pieter Kasselman, Tim Würtele

Cross-device consent phishing attacks employs social engineering techniques against cross-device flows to gain access to the victims data. Instead of stealing the user credential, the attacker tricks the user into giving consent by changing the context of the authorization request. These attacks have continued to evolve and become more sophisticated since they first emerged in 2021. The discussions at OSW in 2022 was instrumental in identifying mitigations and shaping a response that includes new work in the form of an IETF Best Current Practice draft as well as the use of formal analysis to evaluate one of the most commonly used cross-device protocols (the OAuth Device Authorization Grant). In this talk we will explore the evolution of cross-device consent phishing attack techniques as seen in in the wild, how they are targeting additional protocols beyond the OAuth Device Authorization Grant, share progress in terms of practical mitigations and alternative protocols available to practitioners as well as some highlights from the initial formal analysis of the Device Authorization Grant.

Formal Analysis of FAPI 2.0 and the OAuth Device Authorization Grant

Institute of Information Security

In this talk, we present the (intermediate) results of a comprehensive formal security analysis conducted on two prominent security protocols used in modern identity and access management systems: the FAPI 2.0 protocol and the OAuth Device Authorization Grant. Both analyses were carried out with the objective of identifying vulnerabilities and proposing effective countermeasures to enhance the overall security of these protocols.

Firstly, we delve into our analysis of the FAPI 2.0 protocol, which was commissioned and supported by the OpenID Foundation. Our investigation, which assumed the strong attacker model outlined as part of the FAPI 2.0 specifications, uncovered several security issues within the protocol.

Furthermore, as part of our analysis, we developed and proposed fixes for the identified issues, aiming to bolster the security of FAPI 2.0. We collaborated closely with the OpenID's FAPI WG, leading to the incorporation of some of our recommended fixes into the FAPI 2.0 specifications. We will discuss the specific vulnerabilities addressed, the proposed mitigations, and the impact of these changes on the overall security posture of the protocol.

Moving on, we shift our focus to an ongoing formal security analysis of the OAuth Device Authorization Grant, a mechanism designed to enable secure authorization on input-constrained devices. While this analysis is still ongoing, we have discovered attack scenarios that demonstrate the potential exploitation of the OAuth Device Authorization Grant, even when assuming an authenticated communication channel between end-user and client device. We will present the details of these attack scenarios, which highlight the importance of a comprehensive security analysis. Our ongoing evaluation aims to identify weaknesses, propose mitigations, and contribute to the development of stronger security for the OAuth Device Authorization Grant.

By sharing our findings from the formal security analyses of both the FAPI 2.0 protocol and the OAuth Device Authorization Grant, we aim to raise awareness about the importance of explicit security goals in protocol specifications and rigorous evaluations thereof.

Beyond Scopes: RAR in the Real World

Justin Richer

The OAuth "scope" parameter was revolutionary at the time -- it allowed limited access to an API in a world where the gold standard had been all-or-nothing. But scopes can only get you so far in describing access. Sometimes you need to be very specific for a single transaction, or be able to describe access to a variety of resources in different ways.

The Rich Authorization Request (RAR) extension to OAuth was recently published as RFC9396. We'll go through the basics of how the extension works, how to design API access using it, and how it fits alongside other OAuth technologies.

Tutorial: How to build interoperable decentralized identity systems with OpenID for Verifiable Credentials

Kristina Yasuda

OpenID for Verifiable Credentials (OID4VC) is a set of protocols that enables issuance and presentation of verifiable credentials expressed in any format including but not limited to W3C vc-data-model and ISO/IEC 18013-5 mDL. The power of the protocols lies in its demonstrated simplicity, security, and the implementer's ability to make choices across the tech stack - not just for credential formats, but also entity identifiers, trust model, crypto suites, revocation mechanism, etc. However, this also means that to be interoperable and

enable certain use-cases(s), implementers need to agree on the sets of choices across the tech stack, usually referred to as interoperability profiles.

The goal of this session is to share implementation experience of OID4VC specifications, and introduce existing interoperability profiles based on OID4VC. Of course updates to OID4VC specifications, how they have evolved from the last year based on an overwhelming amount of implementation feedback will also be covered.