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=40backbase....@dmarc.ietf.org> 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
