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
On 2/17/22 4:32 PM, Brian Campbell wrote:
On Thu, Feb 17, 2022 at 12:28 PM George Fletcher
wrote:
Given that the FAPI 2 baseline is requiring either DPoP or MTLS as
the sender-constraining methods, I think we need to provide more
guidance about how DPoP is used in cases outside
Hi David,
Rifaat reminded me that yours is the only WGLC comment that has not been
resolved by publication of -01. As noted earlier, the substantive differences
between this draft and the JWK URI draft that you’re proposing are being
primarily discussed in the OpenID Connect working group,
On Thu, Feb 17, 2022 at 12:28 PM George Fletcher wrote:
> From an authorization server perspective, I think it makes sense to be
> able to flag certain clients as only supporting DPoP bound tokens and hence
> rejecting any request without the appropriate proof.
>
There's work underway over in
Hi George,
the main reason for this is to facilitate a client implementation that
always sends the same kind of proof. For the client, there's no need to
distinguish between token request, resource request, or even PAR
request. Even though the key would only be needed once, of course.
From an authorization server perspective, I think it makes sense to be
able to flag certain clients as only supporting DPoP bound tokens and
hence rejecting any request without the appropriate proof.
Given that the FAPI 2 baseline is requiring either DPoP or MTLS as the
sender-constraining
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
Hi,
I'm going to expose my ignorance here... but what is the rationale for
requiring the public key in every DPoP proof? Is there a security
reason? or is it for ease of development? If large RSA keys are being
used, that public key is rather large for sending with every request
when even a
