Re: [OAUTH-WG] draft-fett-oauth-dpop-01 implementation feedback

[Brian Campbell <[e-mail]>]

On Thu, May 2, 2019 at 12:33 AM Paul Querna <[e-mail]> wrote:

> Overall the spec felt functional, though I think the biggest gaps for
> a deployment are with the Access Token interactions, but this makes
> sense since that seems to be addressed in the future by
> <https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00>
>

This DPoP document should aspire to provide sufficient info on access token
interactions so as not to have any dependency on
draft-ietf-oauth-access-token-jwt. And I sorta doubt that PoP style tokens
will be in scope for draft-ietf-oauth-access-token-jwt at all.

Sections 6[a] and 8[b] of DPoP aim to define access token usage. Is there
specific content that you feel is missing in the draft?

[a] https://tools.ietf.org/html/draft-fett-oauth-dpop-01#section-6
[b] https://tools.ietf.org/html/draft-fett-oauth-dpop-01#section-8



> Is there a use case for this being present in the DPoP-Proof JWT?  As
> I've implemented DPoP, I didn't see how it was helpful to be sent as a
> `cnf` claim of the Proof?
>

As David alluded to in his reply yesterday, this is an area that is likely
to see some changes in the next revision of the draft - like doing away
with the distinction between binding and proof, moving the proof key out of
the JWT and less inappropriate use of the `cnf` claim.

But in the -01 draft the key is included with the access token via the
`cnf` claim and you're right that it's not particularly helpful to have it
also sent with the Proof.



> Request Headers vs Parameters
> > 5.  Token Request (Binding Tokens to a Public Key)
>
> Placing the DPoP Binding JWT in the HTTP Header `DPoP-Binding` is
> different than most other OAuth extensions that I am familiar with.
> It is easy in the Go OAuth2 library to add URL / /body params to the
> `/token` endpoint, but it is impossible to add an HTTP Header.  Is
> there a reason that the binding can't be sent as an OAuth Parameter in
> the token request body?
>

Also as David alluded to in his reply yesterday, there's a goal to have the
proof mechanism be the same for accessing the token endpoint as when
accessing resources. And using application/x-www-form-urlencoded parameters
for resource access is problematic for a litany of reasons.



HTTP Request signing may be a quagmire that this spec wishes to avoid,
>

Very much so, yes.


[snip] I'm not sure where the spec-author team wants to take this area, but
> am interested in providing feedback.
>

Somehow cleanly allowing for it by extension would be nice from the
perspective of this document. But full treatment of HTTP signing is
explicitly a non-goal of the DPoP draft with the intent that it have only a
minimal set of stuff that's signed so as to facilitate the
proof-of-possession.


JWT as AT
> >  7.  IANA Considerations
> >
> >    [[TODO: MIME type registration for at+jwt ]]
>
> Assume this will eventually be done via
> <https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00>
>

That's already where it is, no?



Thank you for the work so far, and I'm happy to provide further
> feedback as the spec evolves.
>

Thanks Paul, it's just a -01 version of an individual draft at this point
(with all the authority thereby bestowed on it
<https://tools.ietf.org/html/draft-abr-twitter-reply-00>) but your
participation would certainly be appreciated as the spec evolves and if
it's something the working group decides to pick up as a working group
item.

-- 
_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._