Session Proposals

Open Banking - Direct Mode

The Direct Mode is a proposal for extending the reach of Open Banking APIs with payments as primary target. The concept builds on a secure bootstrap process using OAuth2. After the bootstrap, users can pay with dedicated payment credentials including EMV cards. The Direct Mode is a lightweight alternative to progress-constraining extension-schemes like Embedded SCA.

End to end encryption

The End-to-End Encryption Task Force of the Financial Data Exchange (FDX) Security & Authentication Working Group is chartered to define a proposed specification for sharing certain sensitive customer information within the financial ecosystem. During the past few months, the members of the E2E Encryption Task Force have defined an end-to-end encryption design specification for adoption as part of the FDX standard. This talk will cover the challenges in defining an end to end encryption strategy, and the proposed solutions

Micah Silverman

Hacking OAuth: Pitfalls and Remedies

Witness a practical demo of an authorization code injection attack! You'll see how our Hax0r D00d assumes the identity of the R00b D00d.

Spoiler alert: Using the PKCE extension with a confidential client thwarts this attack. You'll see this in action too.

One note: I'll be presenting at a Ukraine meetup between 11:30 and 13:30 (GMT-4) tomorrow, so if this session is a go, we'll need to schedule around that.
Micah Silverman, 22.07.2020
Isn't Ukraine GMT+4 in the summer?
Vladimir Dzhuvinov, 23.07.2020
Michael B. Jones

Hybrid Application Authorization Code Flow Extensions

An application development pattern we've seen is one of combined front- and back-end authentication, e.g. for server-side rendering of a single-page app. When the implicit flow was a recommended and feasible solution, applications would use the authorization code flow to authenticate the back-end, and then use the implicit flow to authenticate the front-end silently. This resulted in a single auth prompt for users, a desired user experience.

As privacy-conscious features in browsers block the use of 3rd party cookies, this pattern is no longer supported, and popular opinion on the implicit flow is turning. Applications could do two separate code flows to authenticate the front- and back-end separately, but this set of redirects is unappealing for users. Instead, we propose an extension to the confidential client authorization code flow to allow the back-end to request a new authorization code suitable for redemption on the front-end.

This is work driven by Hirsch Singhal of Azure Active Directory, who will also participate. See the proposal at https://github.com/hpsin/HybridCodeFlowProposal/blob/master/Hybrid-App-OAuth.md .

8 am PST or later
Daniel Fett, 23.07.2020

OAuth 2.0 for Browser-Based Apps

Let's discuss building OAuth applications in the browser-based app environment, and what are the particular considerations that need mentioning.

Specifically, we'll collect feedback on the parts of the OAuth 2.0 for Browser-Based Apps draft that still need work. We'll discuss the architecture where the OAuth flow is performed in a Web Worker, isolating the tokens from the main browser window scope.

app2app in oauth2 / mobile apps for authorization servers

Following on from the app2app talk, let's talk more about the security model, recommendations / anti patterns, alternative implementations, and whether anything should be standardised,.

Thanks for submitting the proposal, Joseph! Fabian Hauck and I would like to discuss different methods to redirect from one app to another on a mobile OS. The challenge hereby is to protect the redirection from beeing hijacked by a malicious app and handling the case where no AS app is installed. The goal is to either directly redirect the user to the app without an app selection dialog or to open the user's default browser if the app is not installed. We are especially interested in hearing from people who have experience with App2App redirection on iOS. We will bring some running examples.
Daniel Fett, 22.07.2020
Sounds good Daniel, I'd love to see your examples. I have some running prototype-style code on iOS I can show too.
Joseph Heenan, 23.07.2020
It would be also great if we could talk about device and app integrity - e.g. how to properly integrate SafetyNet.
Miles Stötzner, 23.07.2020
We plan to continue this on Friday, particularly points to cover: 1. Continuing the Android discussion about UX and security 2. Considering standardisation of first party mobile app <-> AS communication 3. App integrity / SafetyNet We hope to have guests from at least one UK bank that implemented app2app last year.
Joseph Heenan, 24.07.2020

OAuth Rich Authorization Requests

The OAuth 2.0 authorization framework [RFC6749] defines the parameter "scope" that allows OAuth clients to specify the requested scope, i.e., the permission, of an access token. This mechanism is sufficient to implement static scenarios and coarse-grained authorization requests, such as "give me read access to the resource owner's profile" but it is not sufficient to specify fine-grained authorization requirements, such as "please let me make a payment with the amount of 45 Euros" or "please give me read access to folder A and write access to file X".

This session is about Rich Authorization Requests (RAR), a new OAuth draft allowing clients to specify their fine-grained authorization requirements using the expressiveness of JSON data structures.

https://tools.ietf.org/html/draft-ietf-oauth-rar-01

https://tools.ietf.org/html/draft-ietf-oauth-rar-01 is the WG adopted and more recent draft
Brian Campbell, 23.07.2020
thanks
Torsten Lodderstedt , 23.07.2020

Pushed Authorization Requests

This session introduces OAuth 2.0 Pushed Authorization Requests (PAR).

https://tools.ietf.org/html/draft-ietf-oauth-par-02

PAR is an OAuth extensions allowing clients to send the authorization request payload to the AS in a backend request instead of going through the front channel.

This has many advantages in comparison to traditional authorization requests:

- there is only a reference to the request object sent through the browser, making the mechanisms robust and secure while allowing the client to pass virtually unlimited payloads

- the client is authenticated and authorized before the user interaction starts, which improves security and usability

https://tools.ietf.org/html/draft-ietf-oauth-par-02 is the most recent draft
Brian Campbell, 23.07.2020
you are right, it was obviously to late yesterday :-)
Torsten Lodderstedt , 23.07.2020

WebID - A privacy preserving federated identity Web API

WebID is an early exploration of ways that Browsers can help users of the Web make safer decisions while logging in on websites with identity providers with high-level purpose-specific APIs.

https://github.com/WICG/WebID

Let's read through this proposal together and discuss how it relates to OAuth!

I just heard about this proposal recently and have only done a cursory reading, so I am by no means an expert on it, so this won't be a presentation so much as a joint learning experience!

Improve accessibility/awareness of OAuth2/OIDC for developers

Developers mostly do not read the OAuth specs, instead, they tend to look up insecure solutions in StackOverflow, etc.

I would like to discuss/collect how we can better reach the developers regarding implementing OAuth in a secure way. One idea for example could be to add an OWASP cheat sheet for OAuth 2 & OpenID Connect but it would be great to have lots of more ideas.

Daniel Fett

DPoP - Demonstrating Proof of Possession

In this session, we'll explore the DPoP draft together.

In order to be able to create or vote for proposals, you need to be logged in. you can log in and register here