Subject: [OAUTH-WG] DPoP and OpenID Connect

From: Dmitry Telegin <[email-masked]>
Date: Thu, 17 Feb 2022 02:03:26 +0300

Could we somehow clarify the relationship between DPoP and OIDC? (sorry if
this is the wrong ML)

For example, it's relatively obvious that the OIDC UserInfo should support
DPoP, as it is an OAuth 2.0 protected resource. What's not obvious is that
the WWW-Authenticate challenge (in case of 401) will most likely contain
multiple challenges (Bearer and DPoP), and it could be a bit tricky from
the browser compatibility PoV.

Another non-obvious thing is that ID tokens could be DPoP-bound as well.
Some technologies even rely on it, Solid-OIDC being a notable example:
https://solid.github.io/solid-oidc/#tokens-id

Dmitry
Backbase / Keycloak

---

From: George Fletcher <[email-masked]>
Date: Thu, 17 Feb 2022 12:15:22 -0500

It's probably better to post this question in the OIDC working group 
email list or file an issue with OpenID Connect. I think it is an 
interesting and relevant question.

OpenID Connect does define the 'private_secret_jwt' mechanism which can 
be used for client authentication and could be bound with the access or 
refresh token.

Thanks,
George

On 2/16/22 6:03 PM, Dmitry Telegin wrote:
> Could we somehow clarify the relationship between DPoP and OIDC? 
> (sorry if this is the wrong ML)
>
> For example, it's relatively obvious that the OIDC UserInfo should 
> support DPoP, as it is an OAuth 2.0 protected resource. What's not 
> obvious is that the WWW-Authenticate challenge (in case of 401) will 
> most likely contain multiple challenges (Bearer and DPoP), and it 
> could be a bit tricky from the browser compatibility PoV.
>
> Another non-obvious thing is that ID tokens could be DPoP-bound as 
> well. Some technologies even rely on it, Solid-OIDC being a notable 
> example: https://solid.github.io/solid-oidc/#tokens-id
>
> Dmitry
> Backbase / Keycloak
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: David Waite <[email-masked]>
Date: Thu, 17 Feb 2022 18:23:24 -0700

Hello Dmitry!

AFAIK there isn’t any accepted work within OpenID Foundation defining an interaction between id_tokens and DPoP.  Like most of the OAuth additions which have come out after OpenID Connect 1.0, one could expect that it would layer on top transparently as something which pertains to access tokens, not id_tokens.

Similar to how OpenID Connect extends OAuth 2.0, I would expect that the use of confirmed id_tokens to be an extension on top of OpenID Connect (in this case, by Solid). I would expect that to be the most appropriate community to engage with.

Within the traditional OpenID Connect model, there is no reason for a client to share its id_token to other parties, or a sense of what sort of decisions another party could make if they receive an id_token which was not meant for them. It is not immediately apparent to me what an id_token with proof of possession would mean to a party which receives it, what additional requirements such an id_token might have, what relationship that other party would have a relationship with the client or OP, or how such an id_token would be sent.

I could see several independent efforts profiling different meanings and usages, which consequently would have different security considerations. In the absence of a proposal for a specification from OIDF, it may be better for these efforts to declare their own new tokens with the semantics they require rather than overloading id_tokens.

-DW

> On Feb 16, 2022, at 4:03 PM, Dmitry Telegin <dmitryt=[email-masked]> wrote:
> 
> Could we somehow clarify the relationship between DPoP and OIDC? (sorry if this is the wrong ML)
> 
> For example, it's relatively obvious that the OIDC UserInfo should support DPoP, as it is an OAuth 2.0 protected resource. What's not obvious is that the WWW-Authenticate challenge (in case of 401) will most likely contain multiple challenges (Bearer and DPoP), and it could be a bit tricky from the browser compatibility PoV.
> 
> Another non-obvious thing is that ID tokens could be DPoP-bound as well. Some technologies even rely on it, Solid-OIDC being a notable example: https://solid.github.io/solid-oidc/#tokens-id <https://solid.github.io/solid-oidc/#tokens-id>
> 
> Dmitry
> Backbase / Keycloak