When designing protocols, one crucial question is: Is the protocol secure? While there are many ways to analyze the security of protocols, formal methods allow for systematic analysis and for finding even new kinds of attacks.

In this session, we start by giving an overview of the basic principle of formal protocol analysis. Then, we introduce the Web Infrastructure Model. This model has been used many times to find attacks on OAuth-related protocols (and other protocols) and also to prove the security of the (fixed) protocols. We continue with presenting two current analyses that we are conducting: formal security analyses of Self-Issued OpenID Provider (SIOP) and the Grant Negotiation and Authorization Protocol (GNAP) specifications. We conclude with a short peek into current work to mechanize the Web Infrastructure Model.

The session will introduce current work conducted by OpenID Foundation in liaison with Decentralized Identity Foundation to utilize OpenID Connect for building SSI application. The focus will be especially on presenting and discussing a new proposal for a OpenID Connect profile that allows OPs to issue Verifiable Credentials to Holders / Wallets.

OpenID Connect Advanced Syntax for Claims defines an extension of OpenID Connect to enable new features for requesting and receiving Claims and meta information about Claims.

The specification defines two independent extensions, Selective Abort/Omit (SAO) and Transformed Claims (TC).

SAO gives RPs the tools to define what behavior they expect when data about the End-User is not available, does not match the RP's expectations, or cannot be released for other reasons. This ensures that data is only transferred when it is useful for the RP, helping privacy and avoiding billing of data useless to the RP.

Transformed Claims defines a syntax and functions for deriving new Claims from existing Claims. This enables new use cases like age verification, the release of selected data from combined Claims (like the ZIP code), and new filters (like value/values) without the introduction of custom Claims. Thanks to Predefined Transformed Claims (PTC), this specification can be implemented with minimal overhead.

One of the major problems with GNAP draft-08 is that the trust relationships are left undefined and are replaced by a "promise model" which is inadequate. It is hard to build a secure system with undefined trust relationships.

OAuth and GNAP draft-08 postulate that only two classes of access tokens may exist: key-bound access tokens and bearer access tokens. However, a third class is possible : user-identifier-bound access tokens. In order to be secure, this class mandates the support of end-user attributes in access tokens. Such support is in the charter of the GNAP working group and reflected by the definitions, but is currently absent in draft-08.

At the moment, GNAP only supports capabilities (called "rights" in the document). How to add the support attributes in GNAP will be explained.

Since a given AS does not necessarily know all the attributes from a given end-user, a RS should be able to trust more than one AS. The model in draft-08 is restricted to a single AS which is fine for an enterprise environment, but not for servers spread all over the Internet.

Access tokens that contain a binding user-identifier (buid) field provide a protection against collusions between two collaborative clients that key-bound access tokens are unable to provide.

The use of a binding user-identifier (buid) field allows a client to choose between different contexts and between different privacy properties.

The privacy differences between the use of capabilities and the use attributes will be explained both from an AS point of view and a RS point of view.

GNAP should also be usable within the EU and hence should take into consideration the EU legislation.

All the previous considerations pave the way towards a modified model.

More details are already present in https://www.ietf.org/id/draft-pinkas-gnap-core-protocol-00.txt

OAuth 2.1 is an in-progress effort to consolidate and simplify the most commonly used features of OAuth 2.0. Highlights of OAuth 2.1 include:

* PKCE is a required part of the authorization code flow

* Implicit and Password grants are omitted

* Refresh tokens should be sender-constrained or one-time use

* Lots of editorial cleanup to bring the spec up to date!

The OAuth working group has continued to make progress on OAuth 2.1 over the past year, but there is still more to do!

In this session I would like to provide a summary of the current status of the draft, as well as open the floor to discuss the current open issues.

https://oauth.net/2.1/

RPs can use the OIDC Claims Request to specify at runtime the need for specific claims and authentication strengths. However, should an RS encounter the same need for reauthentication or additional information in the token, there exists no mechanism for the RS to accomplish that goal. Reasons for needing this range from lack of MFA to CAEP-driven token or session revocation.

We propose a new extension to OAuth2 and OIDC, the "claims challenge", that an RS can provide to an RP, in order to trigger a claims request to the AS on behalf of the RS. Standardized mechanisms for RP RS and RP behavior are proposed, as well as the expansion of the claims request pattern in OIDC.

A strawdog proposal to get the conversation started can be viewed here, looking forward to the discussion on how to proceed:

https://github.com/hpsin/ClaimsChallengesForResources/blob/main/README.md

Step-up authentication is one of the most common production scenarios. A client attempts to access a resource; the resource demands a stronger authentication level than the one indicated by the credentials presented; the client leads the user thru a process that elevates the authentication strength; the client repeats the call with elevated credentials, and the resource grants access.

OAuth 2 provides affordances to implement all of the above, but the lack of specifics led to multiple, incompatible approaches.

This session will put the problem in focus, and will hint at a proposal to achieve interoperable step-up capabilities with minimal or no changes to existing authorization servers, resource servers and clients.

Cross device flows allows users to initiate an action on one device and then authenticate or authorize that action on a trusted device like a mobile phone. An example of this includes authorizing a smart TV to access streaming content, or authenticating to a service by scanning a QR code with a mobile phone. This process of authorizing an action on a separate (but trusted) device from the one on which an action is initiated is an increasingly common flow, whether used for devices with limited input capabilities, multi-factor authentication or credential presentation. Reflecting the popularity of these flows, a number of standards support it, including Device Authorization Grant (formerly Device Code Flow (DCF)), Client Initiated Backchannel Authentication (CIBA) and Self Issued OpenID Provider (SIOP).

However, despite existing implementation guidance and mitigations, attackers are able to exploit these standards based flows using phishing and other social engineering attacks, which allows them to gain access to customer systems and data. The purpose of this session is to start the conversation on additional risk mitigations to secure cross device flows while still allowing users to initiate an action on one device and then authenticate and authorize that action on a separate trusted device.

I would like to discuss the question of whether it would be useful to pursue standardized user interfaces for web sites that promote OAuth-based login. My end-goal is to improve user awareness and privacy-informed choices (and better interfaces). In related work [1], we found that some RPs among the top 500 sites (in each of five different countries) request different amounts of user data from different IdP logins, often with one choice considerably more privacy-intrusive than others. In many cases, users see the permissions related to a particular IdP choice only after deciding to login using that IdP, meaning that the consequences of alternative choices are not visible. This can result in users providing access to more data than they might otherwise choose, if fully-informed.

Towards exploring effective methods to inform privacy-conscious users, if we consider standardized OAuth login interfaces for RPs, we might ask: what are the design requirements or information to be displayed, for a privacy-friendly interface? As we are in the early stage of this work, any input or suggestions would be appreciated. I will also present a short summary of the analysis and findings in our WPES 2021 paper [1], and discuss future directions in enhancing end-user privacy in OAuth systems.

[1] S.G. Morkonda, S. Chiasson, P.C. van Oorschot. Empirical Analysis and Privacy Implications in OAuth-based Single Sign-On Systems. In WPES 2021. https://www.ccsl.carleton.ca/~smorkonda/papers/morkonda-wpes21.pdf

In this talk I will introduce our eSSIF funded (https://essif-lab.eu/) project "Enabling Zero Trust Architectures using OAuth2.0 and Verifiable Credentials (ZeroTrustVC)". In this project we are using OAuth 2.0 to manage the lifecycle of Verifiable Credentials (VCs). I will present how we map entities from VC data model to OAuth 2.0, as well as how we use DPoP to provide VC proof of possession. Additionally, I will discuss how OAuth can benefit from concepts related to VCs, focusing on revocation, wallets, and the use of "Decentralized Identifiers" in DPoP proofs.

The work that will be presented in this talk is based on the paper:

N. Fotiou, V.A. Siris, G.C. Polyzos, "Capability-based access control for multi-tenant systems using OAuth 2.0 and Verifiable Credentials," Proc. 30th International Conference on Computer Communications and Networks (ICCCN), Athens, Greece, July 2021 (https://mm.aueb.gr/publications/0a8b37c5-c814-4056-88a7-19556221728c.pdf)

HTTP Message Signatures is a current draft in the HTTP Working Group of the IETF:

https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-06.html

This draft provides a general purpose mechanism for providing signing over an HTTP message. I've proposed a simple means to apply this mechanism to OAuth 2, which has yet to be picked up by the OAuth WG:

https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-00.html

In this talk, I'll go over how HTTP Message Signatures work and how they could be applied to OAuth 2. HTTP Message Signatures are already an option for a core security mechanism in GNAP.

The Grant Negotiation Authorization Protocol (GNAP) builds on years of experience with OAuth 2.0, OpenID Connect, and the large ecosystem of OAuth-adjacent protocols. In this session, I'll go over the foundational pillars of GNAP's protocol and system design and discuss the current state of the protocol specification in the IETF.

https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-08.html

This talk will have both high-level and technical elements to it, depending on where the discussion wants to track.

The IETF GNAP working group provides an alternative model for authorization (https://datatracker.ietf.org/wg/gnap/documents/).

Draft version 8 (https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-08.html) is now stable enough to start a formal security verification. Preliminary trust relationships description, as well as privacy and security considerations, have been provided. We'd like to engage with both identity professionals and academia to go further into that direction.

The session will review some threats and proposed mitigation strategies.

MITRE, in support of the U.S. Government, has developed tailored OAuth 2.0 (OAuth 2.1 in draft) Token Exchange profiles for use in an enterprise environment. These documents enable “identity chaining” by ensuring that the identities of the user, client, and protected resources are propagated in the issued access tokens to make appropriate access decisions.

We are seeking additional feedback from Subject Matter Experts throughout the Community.

The current profiles are located at

https://www.mitre.org/publications/technical-papers/token-and-identity-chaining-between-protected-resources-in-a-single-icam-ecosystem-using-oauth-token-exchange

https://www.mitre.org/publications/technical-papers/token-and-identity-chaining-between-protected-resources-in-a-multiple-icam-ecosystem-using-oauth-token-exchange

The first describes token chaining in a “single ICAM ecosystem,” where all protected resources trust the same authorization server (e.g., because they all belong to the same organization). The second describes the more complicated case of a “multi ICAM ecosystem,”where at least one protected resource trusts a different authorization server (e.g., because it belongs to a different organization).

WebRTC is a very common technology these days. Lots of multimedia applications like Jitsi Meet, Discord, or WhatsApp use it to transfer real-time audio and video streams directly between web clients.

But all of these applications have one thing in common: Either you must create an account at the service provider or users can join video sessions anonymously without the opportunity to identify them.

OpenID Connect can solve this issue, but it requires some considerations to apply it to peer-to-peer (P2P) environments.

I would like to discuss a solution to authenticate WebRTC peers by any OpenID Connect Identity Provider and without any centralized Authorization Server required.

The solution draft combines existing WebRTC security mechanisms with them of OAuth and OpenID Connect to make it suitible even for financial-grade applications.

This March, FAPI 1.0 Part 1 and Part 2 became OpenID final specifications. To comply with them, there are many active movements globally. As the same as other OAuth-related specifications, several Security Considerations are described in these specifications, "Identity provider mix-up attack" is one of them. Although this attack is a very complex attack, there are few descriptions and no figures, so it is difficult for implementers to grasp the overall picture of the attack. Of course, there are several mitigations described, these take a little high cost so there may be a case that is a little hard to apply to the real system.

In this presentation, to grasp the overall picture of "Identity provider mix-up attack", we list and figure several patterns and conditions of this attack. And also we list mitigations and describe which mitigation can be effective for which conditions and how much. By doing this, implementers can decide how much they should spend efforts to deal with this attack and which mitigation they should apply.

We'd like to discuss the evolving browser landscape as they attempt to protect users from unsanctioned tracking on the web. As we've seen in the past, many of these changes disrupt or completely break critical identity flows in consumer, work, and school scenarios.

We'd like to discuss:

* the current proposals to maintain identity flows while improving privacy (15m)

* the updated timelines from browsers (5m)

* Industry efforts thus far (10m)

We'd also like to have a BoF-style open discussion with the group. (15m)

Tim Cappalli (Microsoft)

Vittorio Bertocci (Auth0)

We have implemented FAPI 1.0 and its related security standards to the OSS (keycloak : https://www.keycloak.org/ , https://github.com/keycloak/keycloak). During this work, we have found some points we want to share to make FAPI Security Profile more beneficial.

In this talk, we will pick up one of such points, how to apply multiple FAPI and other security profiles dynamically per client’s request.

Considering the situation that a client wants to apply a security profile like FAPI per its request. For example, if the client sends an authorization request with scope parameter including “readonly”, the client expects that FAPI 1.0 Baseline security profile be applied by an authorization server. If the client sends the authorization request with scope parameter including “readwrite”, the client expects that FAPI 1.0 Advanced security profile be applied.

Generally, we can achieve such changing security profiles per client dynamically. However, if the authorization server executes security profile related logics based on values of OAuth 2.0/OpenID Connect client metadata, the following issue may arise.

For example, “tls_client_certificate_bound_access_tokens” is picked up as such the OAuth 2.0 client metadata. The client described above sets “tls_client_certificate_bound_access_tokens = true” explicitly by itself or the authorization server enforces the client to set it to follow FAPI 1.0 Advanced security profile.

When the client wants to access the API requiring “readwrite” scope value for accessing some resource owner’s resource, the client sends the authorization request with scope parameter including “readwrite” in mutual TLS handshake and the authorization server accepts this request.

Consecutively, when the client wants to access the API requiring “readonly” scope value for accessing other resource owner’s resource, the client sends the authorization request with scope parameter including “readonly” in normal TLS handshake. In this case, the authorization server rejects this request because the client sent it without mutual TLS handshake. FAPI 1.0 Baseline security profile does not require Holder-of-Key bound access token so that this request should be accepted.

If the client changed its client metadata before sending this request, the authorization server would accept it. However, by considering the additional workload incurred by this additional changing metadata request, it is not a practical way.

To resolve this issue, we propose three strategies for executing security profile related logics : one security profile per client, resolving conflicts in advance and policy-based logics overriding default client metadata setting based logics. Moreover, we discuss which strategy fits with which use case for securing APIs.

Work is proceeding on a new JOSE primitive called a JSON Web Proof that is very similar the JSON Web Signature spec, but adds the ability to support selective disclosure and unlinkable proofs.

The draft is located at https://github.com/json-web-proofs/json-web-proofs and initial incubation work is being done at the Decentralized Identity Foundation in the Applied Cryptography Working Group (https://identity.foundation/working-groups/crypto.html).

This session will provide an overview, discuss some potential use-cases, and answer any questions.

I would like to discuss the outcomes of my master's thesis on SSO security that was finished in September 2020: https://www.nds.ruhr-uni-bochum.de/media/nds/arbeiten/2020/11/30/Masterarbeit_Lauritz_Holtmann_Single_Sign-On_Security.pdf

In this thesis, multiple IdPs and SPs were evaluated regarding the OAuth BCP and previous research, and common issue patterns were derived. Furthermore, the thesis includes some proposals for extensions of the security considerations.

In this talk I'd like to introduce our distributed, fine-granuled, policy-based resource access control protocol leveraging on Attribute-Based Encryption. The protocol is intended to explicitly address issues such as grant confidentiality, proof of possession, antiforgery... and may be implemented by complementing Oauth 2.0 Implicit Grant flow with a HTTP challenge-response authentication. Also I'd like to show a demo built on our Java-based prototype ABE4JWT (https://github.com/netgroup/abe4jwt). (Suggested duration of this session is 1h+questions). Thanks.

Many OAuth client implementations are not tracking the progress made in the OAuth world regarding security and interoperability. In particular, only a few clients by default follow the OAuth Security BCP or provide the featureset required for FAPI compliance.

In this session, I would like to discuss strategies to track and improve client adoption of security guidelines and interoperability features.

This is based on a discussion started in the OpenID FAPI working group: https://bitbucket.org/openid/fapi/issues/433/track-fapi-compliant-rp-libraries

Let's discuss the current status of DPoP and the next step for this draft.

IETF has already recommended Backend for Frontend Security(BFF) for SPA. I am big fan of BFF and have implemented for angular SPA. BFF has two main point.

Don’t Use Implicit Flow (Already Deprecated in OAuth 2.1)

Don’t store access or id token on browser.

I am trying to implement the same in Blazer WASM. By default WASM template still store security token in browser side. This is what I have done.

https://som-nitjsr.github.io/bff/2021/04/25/BlazorWASMBFF.html