1 | ||||||||
---|---|---|---|---|---|---|---|---|
2 | Tuesday Aug 22 | Wednesday Aug 23 | Thursday Aug 24 | |||||
3 | Auditorium | Lecture Theatre | Auditorium | Lecture Theatre | Auditorium | Lecture Theatre | ||
4 | 08:30 | Coffee/Tea | Coffee/Tea | Coffee/Tea | 08:30 | |||
5 | ||||||||
6 | 09:00 | Welcome | OAuth 2.1 (Aaron Parecki) | When the rubber hits the road: How the OAuth security protocols are rolling out to the thousands of health professionals in Norway (Simone Vandeberg) | 09:00 | |||
7 | ||||||||
8 | 09:30 | Why the Trust Model of OIDC is broken (Petteri Ihalainen, Petri Suvila) | Tutorial: High-security & interoperable OAuth 2: What’s the latest? (Joseph Heenan, Daniel Fett) | A Key Is Not Enough: OpenID Connect Federation 1.0 (Roland Hedberg, Michael B. Jones, Giuseppe De Marco, John Bradley, Vladimir Dzhuvinov) | The insecurity of OAuth 2.0 in frontends (Philippe De Ryck) | 09:30 | ||
9 | ||||||||
10 | 10:00 | Full Disclosure: behind the scenes of SD-JWT (Brian Campbell) | End-to-End User Authentication with OpenID Connect: Use Cases and Benefits (Jonas Primbs) | Formal Verification of the Cedar Policy Language (Darin McAdams) | OAuth 2.0 Redirect URI Validation Falls Short, Literally (Tommaso Innocenti, Matteo Golinelli, Kaan Onarlioglu, Bruno Crispo, Engin Kirda) | 10:00 | ||
11 | ||||||||
12 | 10:30 | AM coffee break | AM coffee break | AM coffee break | 10:30 | |||
13 | ||||||||
14 | 11:00 | Defending Against Cross-Device Consent Phishing Attacks (Pieter Kasselman, Tim Würtele) | Tutorial: How to build interoperable decentralized identity systems with OpenID for Verifiable Credentials (Kristina Yasuda) | Keynote/Invited Talk: Programming Engineers: How Standards Shape the Way We Work (Justin Richer) | What should a secure standards framework for Machine Identities look like? (Pieter Kasselman) | Conformance testing for OpenId for Verifiable Credentials (Joseph Heenan) | 11:00 | |
15 | ||||||||
16 | 11:30 | Formal Analysis of FAPI 2.0 and the OAuth Device Authorization Grant (Institute of Information Security) | Keynote/Invited Talk: TBA (Jonathan Hoyland) | Federation Bubbles (Justin Richer) | 11:30 | |||
17 | ||||||||
18 | 12:00 | Beyond Scopes: RAR in the Real World (Justin Richer) | Identity Theft using In-Browser Communications in Dual-Window Single Sign-On (Louis Jannett) | - | Targeted Logout for OAuth and OpenID Connect (Aaron Parecki) | 12:00 | ||
19 | ||||||||
20 | 12:30 | Lunch | Lunch | Lunch | 12:30 | |||
21 | ||||||||
22 | 13:00 | 13:00 | ||||||
23 | ||||||||
24 | 13:30 | Unconference Planning | Unconference Planning | Unconference Planning | 13:30 | |||
25 | short break | short break | short break | |||||
26 | 14:00 | Unconference slot | Unconference slot | Unconference slot | Unconference slot | Unconference slot | Unconference slot | 14:00 |
27 | ||||||||
28 | 14:30 | 14:30 | ||||||
29 | ||||||||
30 | 15:00 | Unconference slot | Unconference slot | Unconference slot | Unconference slot | Unconference slot | Unconference slot | 15:00 |
31 | ||||||||
32 | 15:30 | PM coffee break | PM coffee break | PM coffee break | 15:30 | |||
33 | ||||||||
34 | 16:00 | Unconference slot | Unconference slot | Unconference slot | Unconference slot | Unconference slot | Unconference slot | 16:00 |
35 | ||||||||
36 | 16:30 | 16:30 | ||||||
37 | ||||||||
38 | 17:00 | Unconference slot | Unconference slot | Unconference slot | Unconference slot | Closing session | 17:00 | |
39 | ||||||||
40 | 17:30 | 17:30 | ||||||
41 | ||||||||
42 | 18:00 | Bus transfer to Windsor | Group Picture in South Quadrangle of Founder's Building | Self-organized Pub Visit | 18:00 | |||
43 | Reception in North Quadrangle of Founder's Building | |||||||
44 | 18:30 | Self-organised walk through Windsor or drinks at the Boatman | 18:30 | |||||
45 | ||||||||
46 | 19:00 | Talk on Royal Holloway's art collection | 19:00 | |||||
47 | Dinner at the Boatman in Windsor | Banquet in Picture Gallery | ||||||
48 | 20:00 | 20:00 | ||||||
49 | ||||||||
50 | 21:00 | 21:00 | ||||||
51 | ||||||||
52 | 22:00 | 22:00 | ||||||
53 | ||||||||
54 | 23:00 | Bus transfer to college | 23:00 |
1 | ||||
---|---|---|---|---|
2 | Tuesday Aug 22 | |||
3 | Auditorium | Lecture Theater | ||
4 | 08:30 | Coffee/Tea | 08:30 | |
5 | ||||
6 | 09:00 | Welcome | 09:00 | |
7 | ||||
8 | 09:30 | Why the Trust Model of OIDC is broken (Petteri Ihalainen, Petri Suvila) | 09:30 | |
9 | ||||
10 | 10:00 | Full Disclosure: behind the scenes of SD-JWT (Brian Campbell) | End-to-End User Authentication with OpenID Connect: Use Cases and Benefits (Jonas Primbs) | 10:00 |
11 | ||||
12 | 10:30 | AM coffee break | 10:30 | |
13 | ||||
14 | 11:00 | Defending Against Cross-Device Consent Phishing Attacks (Pieter Kasselman, Tim Würtele) | Tutorial: How to build interoperable decentralized identity systems with OpenID for Verifiable Credentials (Kristina Yasuda) | 11:00 |
15 | ||||
16 | 11:30 | Formal Analysis of FAPI 2.0 and the OAuth Device Authorization Grant (Institute of Information Security) | 11:30 | |
17 | ||||
18 | 12:00 | Beyond Scopes: RAR in the Real World (Justin Richer) | 12:00 | |
19 | ||||
20 | 12:30 | Lunch | 12:30 | |
21 | ||||
22 | 13:00 | 13:00 | ||
23 | ||||
24 | 13:30 | Unconference Planning | 13:30 | |
25 | short break | |||
26 | 14:00 | Unconference slot | Unconference slot | 14:00 |
27 | ||||
28 | 14:30 | 14:30 | ||
29 | ||||
30 | 15:00 | Unconference slot | Unconference slot | 15:00 |
31 | ||||
32 | 15:30 | PM coffee break | 15:30 | |
33 | ||||
34 | 16:00 | Unconference slot | Unconference slot | 16:00 |
35 | ||||
36 | 16:30 | 16:30 | ||
37 | ||||
38 | 17:00 | Unconference slot | Unconference slot | 17:00 |
39 | ||||
40 | 17:30 | 17:30 | ||
41 | ||||
42 | 18:00 | Bus transfer to Windsor | 18:00 | |
43 | ||||
44 | 18:30 | 18:30 | ||
45 | ||||
46 | 19:00 | Dinner at the Boatman in Windsor | 19:00 | |
47 | ||||
48 | 20:00 | 20:00 | ||
49 | ||||
50 | 21:00 | 21:00 | ||
51 | ||||
52 | 22:00 | 22:00 | ||
53 | ||||
54 | 23:00 | Bus transfer to college | 23:00 |
1 | |
---|---|
2 | Talks & Tutorials Tuesday |
3 | |
4 | Why the Trust Model of OIDC is broken |
5 | Petteri Ihalainen, Petri Suvila |
6 | 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. |
7 | |
8 | |
9 | Full Disclosure: behind the scenes of SD-JWT |
10 | Brian Campbell |
11 | 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. |
12 | |
13 | |
14 | End-to-End User Authentication with OpenID Connect: Use Cases and Benefits |
15 | Jonas Primbs |
16 | 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. |
17 | |
18 | AM coffee break |
19 | |
20 | Defending Against Cross-Device Consent Phishing Attacks |
21 | Pieter Kasselman, Tim Würtele |
22 | 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. |
23 | |
24 | |
25 | Formal Analysis of FAPI 2.0 and the OAuth Device Authorization Grant |
26 | Institute of Information Security |
27 | 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. |
28 | |
29 | |
30 | Beyond Scopes: RAR in the Real World |
31 | Justin Richer |
32 | 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. |
33 | |
34 | |
35 | Tutorial: How to build interoperable decentralized identity systems with OpenID for Verifiable Credentials |
36 | Kristina Yasuda |
37 | 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. |
1 | ||||
---|---|---|---|---|
2 | Wednesday Aug 23 | |||
3 | Auditorium | Lecture Theater | ||
4 | 08:30 | Coffee/Tea | 08:30 | |
5 | ||||
6 | 09:00 | OAuth 2.1 (Aaron Parecki) | 09:00 | |
7 | ||||
8 | 09:30 | Tutorial: High-security & interoperable OAuth 2: What’s the latest? (Joseph Heenan, Daniel Fett) | A Key Is Not Enough: OpenID Connect Federation 1.0 (Roland Hedberg, Michael B. Jones, Giuseppe De Marco, John Bradley, Vladimir Dzhuvinov) | 09:30 |
9 | ||||
10 | 10:00 | Formal Verification of the Cedar Policy Language (Darin McAdams) | 10:00 | |
11 | ||||
12 | 10:30 | AM coffee break | 10:30 | |
13 | ||||
14 | 11:00 | Keynote/Invited Talk: Programming Engineers: How Standards Shape the Way We Work (Justin Richer) | 11:00 | |
15 | ||||
16 | 11:30 | Keynote/Invited Talk: TBA | 11:30 | |
17 | ||||
18 | 12:00 | Identity Theft using In-Browser Communications in Dual-Window Single Sign-On (Louis Jannett) | - | 12:00 |
19 | ||||
20 | 12:30 | Lunch | 12:30 | |
21 | ||||
22 | 13:00 | 13:00 | ||
23 | ||||
24 | 13:30 | Unconference Planning | 13:30 | |
25 | short break | |||
26 | 14:00 | Unconference slot | Unconference slot | 14:00 |
27 | ||||
28 | 14:30 | 14:30 | ||
29 | ||||
30 | 15:00 | Unconference slot | Unconference slot | 15:00 |
31 | ||||
32 | 15:30 | PM coffee break | 15:30 | |
33 | ||||
34 | 16:00 | Unconference slot | Unconference slot | 16:00 |
35 | ||||
36 | 16:30 | 16:30 | ||
37 | ||||
38 | 17:00 | Unconference slot | Unconference slot | 17:00 |
39 | ||||
40 | 17:30 | 17:30 | ||
41 | ||||
42 | 18:00 | Reception in North Quadrangle | 18:00 | |
43 | ||||
44 | 18:30 | 18:30 | ||
45 | ||||
46 | 19:00 | Banquet in Picture Gallery | 19:00 | |
47 | ||||
48 | 20:00 | 20:00 | ||
49 | ||||
50 | 21:00 | 21:00 | ||
51 | ||||
52 | 22:00 | 22:00 | ||
53 | ||||
54 | 23:00 | 23:00 |
1 | |
---|---|
2 | Talks & Tutorials Wednesday |
3 | |
4 | OAuth 2.1 |
5 | Aaron Parecki |
6 | Since the original publication of OAuth 2.0 (RFC 6749) in 2012, several new RFCs have been published that either add or remove functionality from the core spec, including OAuth 2.0 for Native Apps, Proof Key for Code Exchange, OAuth for Browser-Based Apps, and OAuth 2.0 Security Best Current Practice. OAuth 2.1 is an in-progress effort to consolidate and simplify OAuth 2.0 by packaging up all the best practices into a new version of the spec. This session will cover the current status of this ongoing work and what you need to know to be prepared for the publication of OAuth 2.1. |
7 | |
8 | |
9 | Tutorial: High-security & interoperable OAuth 2: What’s the latest? |
10 | Joseph Heenan, Daniel Fett |
11 | OAuth is a widely used authorization framework that enables third-party applications to access resources on behalf of a user. However, it has been historically difficult to meet very high security and interoperability requirements when using OAuth. Daniel and Joseph have spent much of the last five years working to improve the state of the art and will present the latest developments in the field. There are challenges when trying to achieve high security and interoperability with OAuth2: There are many potential threats, some not part of the original OAuth threat model. To seamless authorizations, optionality must be minimized OAuth itself and also in any extensions used. Six years ago, the IETF OAuth working group started work on the Security Best Current Practice document and more recently on OAuth 2.1. Meanwhile, the OpenID Foundation has created FAPI1 and FAPI2 security profiles. We will help you understand the focus of each document and when to use which. We show how to achieve on-the-wire interoperability and security through the use of techniques like asymmetric client authentication and sender-constraining via DPoP and MTLS, discussing the benefits and potential disadvantages of each. We highlight the benefits for implementers and the role of conformance testing tools. |
12 | |
13 | |
14 | A Key Is Not Enough: OpenID Connect Federation 1.0 |
15 | Roland Hedberg, Michael B. Jones, Giuseppe De Marco, John Bradley, Vladimir Dzhuvinov |
16 | Large scale identity federations and wallet applications need more than basic public key attestation, handled traditionally by X.509 certificates. The new OpenID specification combines support for real world trust topologies, a rich set of APIs and built-in metadata discovery & policing -- a one-stop solution for attesting entities on the Internet. |
17 | |
18 | |
19 | Formal Verification of the Cedar Policy Language |
20 | Darin McAdams |
21 | Cedar is a new authorization policy language & evaluation engine developed by AWS and open sourced in May 2023. While standards such as OpenID Connect provide authentication, Cedar solves for authorization at a finer granularity than can be expressed by course-grained OAuth scopes. This talk will introduce Cedar, describe the motivations for its creation, and deep-dive into the ways that formal verification techniques have been applied to its development. |
22 | |
23 | AM coffee break |
24 | |
25 | Keynote/Invited Talk: Programming Engineers: How Standards Shape the Way We Work (Justin Richer) |
26 | Justin Richer |
27 | When programming a computer system, developers utters strange and specific incantations in esoteric languages to make the system do their bidding. Computers have the benefit of being fairly predictable. But what if the runtime environment was not so stable? What if one command could get interpreted in a nearly infinite variety of ways? What if even the most fundamental instructions could be simply ignored or countered at any point ... just because? This is exactly the world that standards writers live in, where the standards text is executed on the most unreliable platform possible: the minds of implementors around the world. After all, a standard document is really just a set of instructions with a desired output; it's just that the output is itself a software system and its behavior. So how do you work in this kind of space? By approaching standards with an engineering mindset, both in writing and reading them, systems and protocols can be more robust and predictable for everyone. Come to this talk to find out what you should do, and what you must pay attention to, in the unpredictable world of the internet. |
28 | |
29 | |
30 | Identity Theft using In-Browser Communications in Dual-Window Single Sign-On |
31 | Louis Jannett |
32 | Academic security and privacy research on Single Sign-On (SSO) protocols like OAuth 2.0 and OpenID Connect 1.0 focused on the standardized single-window authentication flows, which rely on HTTP redirects to transfer identity tokens between the Service Providers (SPs) and Identity Providers (IdPs). However, modern web applications like single page applications may not be able to execute single-window SSO because they lose the local state in case of HTTP redirects. By using novel browser technologies, such as postMessage, developers designed and implemented SSO flows that are not standardized and have not been analyzed thoroughly. We call them dual-window SSO flows. In the first part of this talk, we present our recent work published at CCS’22 [1], in which we provided the first comprehensive evaluation of dual-window SSO. In particular, we focused on the in-browser communication used to exchange authentication tokens between SPs and IdPs in iframes and popups. We found that 56% of the SPs in the Tranco top 1k list support dual-window SSO. Surprisingly, 28% of the SPs implemented dual-window SSO without using official SDKs, leading to identity theft and XSS in 31% of these self-implemented SPs. Our ongoing research shows that 50% of the SPs in the Tranco top 1m list support dual-window SSO (20,595 of 41,411 domains, 50%). Our large-scale scan further shows that developers prefer to manually implement dual-window SSO (11,766 of 20,595 domains, 57%), increasing the overall risk for implementation flaws and token leaks. In the second part of this talk, we present prior [2, 3] and discuss preferable future standardization attempts of dual-window SSO. The increased attack surface of dual-window SSO has been addressed with the recent inclusion of "Attacks on In-Browser Communication Flows” into the OAuth 2.0 Security Best Current Practice [4]. However, the standardization of dual-window SSO is still open for discussion. Thereby, we also consider current and future browser cookie policies and how they have an impact on SSO in general. [1] https://dl.acm.org/doi/10.1145/3548606.3560692 [2] https://datatracker.ietf.org/doc/html/draft-ideskog-assisted-token-05 [3] https://datatracker.ietf.org/doc/html/draft-sakimura-oauth-wmrm-00 [4] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-attacks-on-in-browser-commu |
1 | ||||
---|---|---|---|---|
2 | Thursday Aug 24 | |||
3 | Auditorium | Lecture Theater | ||
4 | 08:30 | Coffee/Tea | 08:30 | |
5 | ||||
6 | 09:00 | When the rubber hits the road: How the OAuth security protocols are rolling out to the thousands of health professionals in Norway (Simone Vandeberg) | 09:00 | |
7 | ||||
8 | 09:30 | The insecurity of OAuth 2.0 in frontends (Philippe De Ryck) | 09:30 | |
9 | ||||
10 | 10:00 | OAuth 2.0 Redirect URI Validation Falls Short, Literally (Tommaso Innocenti, Matteo Golinelli, Kaan Onarlioglu, Bruno Crispo, Engin Kirda) | 10:00 | |
11 | ||||
12 | 10:30 | AM coffee break | 10:30 | |
13 | ||||
14 | 11:00 | What should a secure standards framework for Machine Identities look like? (Pieter Kasselman) | Conformance testing for OpenId for Verifiable Credentials (Joseph Heenan) | 11:00 |
15 | ||||
16 | 11:30 | Federation Bubbles (Justin Richer) | 11:30 | |
17 | ||||
18 | 12:00 | Targeted Logout for OAuth and OpenID Connect (Aaron Parecki) | 12:00 | |
19 | ||||
20 | 12:30 | Lunch | 12:30 | |
21 | ||||
22 | 13:00 | 13:00 | ||
23 | ||||
24 | 13:30 | Unconference Planning | 13:30 | |
25 | short break | |||
26 | 14:00 | Unconference slot | Unconference slot | 14:00 |
27 | ||||
28 | 14:30 | 14:30 | ||
29 | ||||
30 | 15:00 | Unconference slot | Unconference slot | 15:00 |
31 | ||||
32 | 15:30 | PM coffee break | 15:30 | |
33 | ||||
34 | 16:00 | Unconference slot | Unconference slot | 16:00 |
35 | ||||
36 | 16:30 | 16:30 | ||
37 | ||||
38 | 17:00 | Closing session | 17:00 | |
39 | ||||
40 | 17:30 | 17:30 | ||
41 | ||||
42 | 18:00 | Self-organized Pub Visit | 18:00 | |
43 | ||||
44 | 18:30 | 18:30 | ||
45 | ||||
46 | 19:00 | 19:00 | ||
47 | ||||
48 | 20:00 | 20:00 | ||
49 | ||||
50 | 21:00 | 21:00 | ||
51 | ||||
52 | 22:00 | 22:00 | ||
53 | ||||
54 | 23:00 | 23:00 |
1 | |
---|---|
2 | Talks & Tutorials Thursday |
3 | |
4 | When the rubber hits the road: How the OAuth security protocols are rolling out to the thousands of health professionals in Norway |
5 | Simone Vandeberg, Product owner for NHNs trust framework and formerly product owner for NHNs autorization server and its self-service application |
6 | At the end of this presentation, you will know more about how OIDC and OAuth are being used in the context of healthcare, a highly critical, life-and-death, scenario. The health sector in Norway is enabling health professionals to digitally access health information, giving them access regardless of where the information is stored. Heath information includes, for example, prescriptions, medical images and test results, medical IOT device information, patient records, care plans, and clinical registries. In Norway, digitally sharing healthcare information across legal entities is a fundamental change. Health professionals themselves have the legal basis for accessing health information. They do not require pasient consent. However, both the legal entity accessing health information and the legal entity that collected the information are considered data collectors. Thus, both are responsible for ensuring that the transaction is authorized and managed in accordance with the law. Another challenge is that the sector is both fragmented and diverse. To help ensure that access is given in accordance with the law, Norsk Helsenett (NHN) is establishing an ecosystem of legal entities that agree to use a trust framework as the basis for sharing. The trust framework, also being established by NHN, documents the agreed rules and mechanisms for sharing. It includes identity federation using OIDC and OAuth for delegation. In NHNs roll as the sector's trusted 3rd party, the organization is facilitating reinterpreting and realigning existing laws. In addition NHN is helping health organizations reevaluate their requirements and processes. In addition, NHN is developing and implementing new concepts and solutions across the sector. In this work, NHN faces challenges like building an understanding of trust concepts and technologies, agreeing a shared way of determining and expressing legitimate interest, agreeing the appropriate investment in information security, and operationalizing technical solutions across the sector. In this presentation I will talk about how OIDC and OAuth are rolling out to the thousands of health professionals in Norway. I will cover: • How NHN builds its trust framework and ecosystem for digital sharing health information, • How NHN informs and enforces its OIDC and OAuth security requirements that based on FAPI 2.0, • How NHN enables the data controlling and data processing legal entities to implement OIDC and OAuth according to NHNs requirements, • How NHNs OIDC and OAuth security requirements affect the architectural patterns for different types of technologies and software, • How NHNs uses protocol mechanisms such as token exchange, and • How NHN uses the protocols to ensure the required level of assurance and leverages the protocols to meet the need for accountability. |
7 | |
8 | |
9 | The insecurity of OAuth 2.0 in frontends |
10 | Philippe De Ryck |
11 | Everyone agrees that Cross-Site Scripting (XSS) is a real threat to browser-based applications, but many underestimate the true power of XSS. In fact, various OAuth 2.0 security mechanisms for frontends, such as refresh token rotation or token isolation in workers, fail to look beyond script kiddie XSS attacks. In this talk, we take an in-depth look at the consequences of XSS in frontend OAuth 2.0 clients. We explore real-world attacker capabilities and map them against a concrete threat model. We also explore how structural solutions like the Backend-for-Frontend pattern effectively increase the security of frontend applications. The goal of this session is to establish a baseline understanding of security in frontend OAuth 2.0 clients, so that we can consolidate the current guidelines in the specifications into risk-based developer-oriented recommendations. Ideally, this session is followed-up by a breakout meeting to flesh out the details. |
12 | |
13 | |
14 | OAuth 2.0 Redirect URI Validation Falls Short, Literally |
15 | Tommaso Innocenti, Matteo Golinelli, Kaan Onarlioglu, Bruno Crispo, Engin Kirda |
16 | OAuth 2.0 is an industry-standard delegated access protocol allowing Internet users to grant a web application access to their data hosted on a third-party server. The most widely-used mechanism provided by OAuth 2.0, the Authorization Code Grant flow, involves multiple interactions between a Client application requesting access to external data and an Identity Provider (IdP), where sensitive parameters need to be securely transferred and processed by each party. In particular, the "redirect URI" parameter, included in the popular Authorization Grant Code flow, governs the callback endpoint that users are routed to together with their security tokens. The protocol specification, therefore, includes guidelines on protecting the integrity of the redirect URI. In this work, we analyze the OAuth 2.0 specification in light of modern systems-centric attacks; here vulnerabilities stem from the discrepancies between how different system components parse the same URI. We reveal that the RFC guidance available for Clients and IdP narrowly focuses on protecting the integrity of the domain name included in redirect URI alone, but not the entire URI, exposing IdPs to path confusion and parameter pollution attacks. Based on this observation, we propose novel attack techniques and experiment with 16 popular IdPs. We empirically verified that the OAuth 2.0 security guidance is under-specified. Our experiments show that they expose vulnerabilities due to insufficient validation of redirect URI, even under the charitable assumption that they follow the relevant RFCs flawlessly. Specifically, 5 IdPs are vulnerable to path confusion, and 10 are susceptible to parameter pollution attacks. Using these vulnerabilities as novel exploit building blocks and combining them with other Client and IdP vulnerabilities, we show that sensitive OAuth 2.0 parameter leakage leads to complete account takeover. Following a coordinated disclosure process, we have shared our findings with the impacted parties. We have also identified the parts of the OAuth 2.0 specification where redirect URI validation requirements are under-specified, leading to the vulnerabilities we have discovered, and made recommendations to the OAuth Working Group for improvements to the protocol specification. |
17 | |
18 | AM coffee break |
19 | |
20 | What should a secure standards framework for Machine Identities look like? |
21 | Pieter Kasselman |
22 | We entrust machines (hardware and software) with our most sensitive data, giving them access to far more information than the human on whose behalf it operates, if it is even operating on behalf of a human. Yet, managing machine identities and applying Zero Trust Policies to them is a Herculean task complicated by a heterogenous technology landscape, amplified by multi-cloud/multi-hybrid environments, exacerbated by critical skills shortages and magnified by exponential growth in machine identities. It's the kind of problem standards excel at solving by creating interoperability layers between heterogenous environments, codifying the wisdom of the crowd to alleviate pressures on rare skills, and creating eco-systems of interoperable solutions that meet a common security bar. Fortunately there are already several standards efforts that can help us manage machine identities. Some of these are building on standards for human identities, while others are focused exclusively on machines. But how are all these efforts related and how to we avoid replacing a patchwork of heterogenous solutions with a patchwork of heterogenous standards? Is it possible to craft a standards framework and connect all these efforts in a single identity trust fabric, and is that desirable? If we had such a framework, what would it look like? In this talk we explore the benefits of weaving a secure standards framework for machines by bringing together more than 18 standards from at least 7 standards bodies while identifying opportunities to align and connect them all to solve the emerging challenge of machine identities at scale. |
23 | |
24 | |
25 | Federation Bubbles |
26 | Justin Richer |
27 | We have traditionally thought of federations as relatively static engagements, with significant effort being put into easing the onboarding of entities into the federation. But what about when the needs change over time? Can we build out a robust network of interconnected federation-driven environments for an ever-changing world? We'll talk about the federation bubbles concept and how it relates to existing and emerging security technologies including OAuth, OpenID Connect, Verifiable Credentials, SPIFFE, and others. |
28 | |
29 | |
30 | Targeted Logout for OAuth and OpenID Connect |
31 | Aaron Parecki |
32 | Logging out is an important aspect of security that is often overlooked. While the industry has made significant strides in making logging in more secure with OAuth and OpenID Connect, there are still many challenges remaining with logging out. When it comes to securing user accounts, we often think about password strength, 2-factor authentication, and account recovery methods. However, we often forget about the importance of logging out. A secure logout process is just as important as a secure login process, especially in today's world where users are accessing multiple applications on various devices. Targeted logout is an emerging concept that addresses the security challenges of logging out of multiple applications on a single device. In this session, we will explore the concept of targeted logout and why it is necessary for modern applications. This session will cover the following topics: • The importance of targeted logout in preventing session hijacking, cookie theft, and other security threats. • The challenges of logging out of multiple applications on a single device. Whether this is browsers dropping support of third party cookies, or sandboxed native apps unable to share data, communicating logout information to all applications from an authorization server remains a challenge. • The challenges of linking native app and web browser sessions on the same device. When a native application uses the recommended browser-based login flow, a web session is created on the device along with the tokens issued to the app, but these aren’t necessarily linked today. In this session, we will explore the importance of targeted logout and discuss the tools available for implementing this concept in modern applications. We will cover what tools exist today in OAuth and OpenID Connect for implementing targeted logout, and will identify the gaps where there is a potential for creating new solutions. |
33 | |
34 | |
35 | Conformance testing for OpenId for Verifiable Credentials |
36 | Joseph Heenan |
37 | Digital wallets and verifiable credentials are currently a hot topic in many jurisdictions around the world, with work ongoing in the EU, ISO, Japan, USA and many more that leverages OpenID Foundation (OIDF) standards. OIDF has a history of creating conformance tests and certification programmes for OpenID standards. OIDF is currently working on tests for the OpenID for Verifiable Presentations, OpenID for Verifiable Credential Issuance and OpenID4VC High Assurance Interoperability Profile (HAIP) specifications to ensure that deployments of these protocols are both interoperable and correctly implement the security properties. Joseph talks about the approach being taken, demonstrates the progress to date, and shares the future roadmap and how implementors can run the current tests. |