Re: [OAUTH-WG] [EXT] Re: DPoP followup III: client auth

[Brian Campbell <[e-mail]>]

On Fri, Dec 4, 2020 at 8:21 AM Michael A Peck <[e-mail]> wrote:

> Hi Brian,
>
>
>
> I think I lean towards  “Shut up and never speak of this again”, but could
> you clarify some things?
>

That seems to be where rough consensus is heading. So the clarifications
are likely moot. But I'll try anyway.


>
>
> I missed the interim meeting discussion on this slide – it looks like DPoP
> for client authentication would have very similar properties as
> private_key_jwt, but using DPoP instead? i.e. both use a private key to
> sign a JWT that authenticates the client.
>

Time was running out in the meeting at the same time I somehow lost the
ability to advance slides.  So there wasn't any real discussion on this
one. But yes they would have very similar properties AFAICT.



>
> Could you expand a bit on the advantage of using DPoP for both client
> authentication and sender-constraining the token vs. using private_key_jwt
> (for client authentication) + DPoP (for sender-constraining the token)?
>

The only advantage would be avoiding sending two different JWTs in a one
request that are doing very similar things.  DPoP + private_key_jwt seemed
awkward in that respect when I thought about it. That was really my only
motivation for bringing it up.



>
>
> Adding to Filip’s comment, is there just one DPoP proof sent in the token
> request to cover both client authentication and sender-constraining the
> token, meaning the same keypair would be used for both DPoP usages?
>

That was the idea, yes.



> That would go against DPoP’s key rotation guidance, but maybe would be
> okay if freshness guarantees of the DPoP proof get added?
>

Yes kinda but the kind of client's that could use DPoP for client auth are
likely the kind that could rotate those keys via JWKS_URI and also be less
prone to the vectors (like XSS) which most benefit from rotation. Improved
(guarantee seems too strong a word) freshness probably makes it more okay
too.



>
>
> Thanks,
>
> Mike
>
>
>
>
>
> *From: *OAuth <[e-mail]> on behalf of Filip Skokan <
> [e-mail]>
> *Date: *Thursday, December 3, 2020 at 4:49 AM
> *To: *Brian Campbell <bcampbell=[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *[EXT] Re: [OAUTH-WG] DPoP followup III: client auth
>
>
>
> 🤫, better not open up the possibility of thinking of DPoP Proof keys as
> pre-registered (i.e. not "ephemeral").
>
>
>
> Best,
> *Filip*
>
>
>
>
>
> On Wed, 2 Dec 2020 at 23:30, Brian Campbell <bcampbell=
> [e-mail]> wrote:
>
> There were a few items discussed somewhat during the recent interim
> <https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth>
> that I committed to bringing back to the list. The slide below (also
> available with a few extra spelling errors as slide #19 from the interim
> presentation
> <https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf>)
> is the last of them.
>
>
>
> To summarize, I'm wondering if there's WG interest in working to formalize
> a client-to-AS authentication mechanism based on DPoP. I think it
> potentially would be problematic to put into the current document (for a
> number of reasons) so am preemptively ruling out that option. Thus,
> basically, I'm asking the WG if there is some/much interest in the idea? In
> which case I'll find some time (at some point) to write up an I-D for it
> and bring that back to the group for consideration. Or if I should, as the
> slide says, "shut up and never speak of this again"?
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._