client metadata

[jogu]

This was kind of mentioned in #27 but I think not taken forward as use cases couldn't be seen.

I'm not sure if I've missed something but it seems like there's an argument that if a client supports dpop access tokens, it should be able to indicate so to the server, with an expectation that (whether as a result of a mistake by the client developer, a misconfiguration of the client, or some kind of attack*) that the server could decide not to issue a plain bearer access token.

So similar to tls_client_certificate_bound_access_tokens I wonder about a dpop_access_tokens or similar. But perhaps more generic as there should probably be a way to indicate the use of dpop refresh tokens for public clients too.

[*] admittedly I can't see any mechanism for making such an attack, it seems like an attacker that could force the client to request a bearer token would also be in a position to inject their own public key - perhaps if the server had some kind of requirement that key had been attested to be in a HSM or something, I don't know. The 'developer made a mistake' threat seems more real.

[bc-pi]

It's also come up on the mailing list: https://mailarchive.ietf.org/arch/msg/oauth/6YI7fYrCNZX-PFeGfgLocOJ3mWI/ FWIW

[bc-pi]

And as I said in the mailing list thread, "the requirement to use DPoP is more of a property of a resource so I don't think registration metadata for a client fits very well" and I think that's true unless the client is a DPoP only client (while WG folks have expressed the need/desire for mixed deployments). And AS policy could be used toward the same end.

But with that (confusingly) said, maybe there is enough value in having a common client metadata field that indicates the given client is always going to do DPoP...

Note that MTLS with public clients bind RTs in a similar way and don't have client metadata. I wanted to avoid introducing metadata for something narrow where there was already an in-band signal at runtime. Similar thoughts/feelings here. But maybe, as you suggest, a more generic parameter could cover it. Like, a better named but conceptually: this_client_will_always_send_dpop_header_when_trying_to_get_tokens that when true would allow the AS to reject requests to the token endpoint that don't have DPoP based on a common/standardized piece of metadata.

[bc-pi]

Looking for input from the WG too https://mailarchive.ietf.org/arch/msg/oauth/sXBTLowQfKYN_9VKErxl1e3ys3c/ (which I may well regret)

[selfissued]

If we added an always_uses_dpop client metadata parameter, what actions would we require based upon it?

[selfissued]

Similarly, if we introduced AS metadata saying that the AS supports DPoP, what behaviors would we require based on it?

[jogu]

Similarly, if we introduced AS metadata saying that the AS supports DPoP, what behaviors would we require based on it?

There is AS metadata already, dpop_signing_alg_values_supported. I'm not sure any changes are necessary there.

If we added an always_uses_dpop client metadata parameter, what actions would we require based upon it?

The documentation for tls_client_certificate_bound_access_tokens says:

Note that if a client that has indicated the intention to use mutual-TLS client certificate-bound tokens makes a request to the token endpoint over a non-mutual-TLS connection, it is at the authorization server's discretion as to whether to return an error or issue an unbound token.

So it doesn't actually require any behaviour. I don't know/remember the background for that.

My initial suggestion would be something like:

"If true, the authorization server MUST only issued sender constrained tokens to this client, rejecting requests for non-constrained tokens with an error."

Also I should probably note that https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md requires servers to reject requests without sender constraining, so FAPI2 supporting authorization servers will be required to have that behaviour. The question is really if the dynamic client registration request/response should have a standardised way to communicate that behaviour.

[bc-pi]

I think the wording around always_uses_dpop should center around requiring that the given client send the dpop header in token requests.

[jogu]

Yeah, that's better than my ramblings. so maybe:

If true, the authorization server MUST reject requests from this client which do not contain the DPoP header.