> On May 2, 2019, at 12:32 AM, Paul Querna <pque...@apache.org> wrote:
> Jumping into specific items:
>
> cnf in DPoP-Proof
>> o "cnf": Confirmation claim as per [RFC7800] containing a member
>> "dpop+jwk", representing the public key chosen by the client in
>> JWK format (REQUIRED for DPoP Binding JWTs, OPTIONAL for DPoP
>> Proof JWTs).
>
> 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?
Discussions with some of the authors makes me think the next draft will change
this so that there is no longer a distinction between binding and proof,
instead having the key sent outside the DPoP-Proof JWT while binding (possibly
as another header). This also allows for more potential flexibility for where
the client public key comes from.
Ignoring that, cnf in a proof JWT would allow for debugging/errors to indicate
a key mismatch. I think the current language may be a bit ambiguous as to
whether a JWK set is allowed as “cnf” as it merely says “JWK format"; if sets
are allowed then cnf in the proof would be used for key selection.
> 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?
My understanding is that the goal is to have the proof be applied the same for
accessing the token endpoint as when accessing the resources.
RFC 6750 describes sending the access token as a query parameter or
application/x-www-form-urlencoded form parameter, with recommendations of only
legacy/last resort use and resources having this as MAY to support. I believe
the default position (without strong evidence) is to not carry these forward by
defining additional alternatives for DPoP as a query/form parameter.
>
> HTTP Request Signing
>> o "http_method": The HTTP method for the request to which the JWT is
>> attached, in upper case ASCII characters, as defined in [RFC7231]
>> (REQUIRED).
>>
>> o "http_uri": The HTTP URI used for the request, without query and
>> fragment parts (REQUIRED).
>
> HTTP Request signing may be a quagmire that this spec wishes to avoid,
> but it seems very hard to avoid "fixing" it for at-scale adoption.
> With the Okta-hat on, I think this is one area we would like to see
> some iteration on. I think it would be ideal to not require multiple
> client sign() and server validate() PKI operations per request, so
> this is where combining DPoP-Proof and a Request Signature start
> making sense to me.
>
> Keeping it simple, there are two approaches for DPoP for adding
> attesting about the HTTP Request:
>
> a) Adding parts of the HTTP Request as claims
> b) Adding a hash of an HTTP Request as a claim
>
> For option (b), it seems like part of this could live in a separate spec:
> 1) request canonicalization
> 2) request hashing
>
> <https://tools.ietf.org/html/draft-cavage-http-signatures-11> does
> cover request canonicalization, but the hashing is part of the
> specific signature scheme. From an implementors POV, layering
> draft-cavage-http-signatures-11 in addition to DPoP is annoying since
> it would take two sign or verify key operations per request.
I believe the position at the moment is to keep this close to the bare minimum
necessary for operation as proof of possession - the method, origin and path
which may be used for routing, to allow for a resource server enforce track
one-time-use.
The intersection of HTTP components that intermediaries should or must leave
unmodified per spec, and that are useful for http request signing is basically
empty. Even method and origin/path are often modified by gateways - in such
environments, either the intermediary should be responsible for verifying DPoP
or the resource will need knowledge on how to verify the supplied method,
origin and path (such as via static knowledge or a header added by the
intermediary)
The proof can be extended with additional parameters, which the AS and resource
servers in an environment can require. In this manner, DPoP can be extended to
meet HTTP request signing use cases. HTTP request signing will always be
environment-specific however, and is a big additional ask for a proof of
possession specification.
Cavage request verification, for example, could be mapped into a DPoP extension
by exposing requirements as extensions against the Bearer authorization
request, and embedding the cavage headers and a hash (not digest or signature)
of the output into the proof token. Or perhaps the requirements are exposed as
AS metadata to cover all resources.
-DW
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
