jogu
commented
5 months ago This is text that came from https://www.rfc-editor.org/rfc/rfc8252#section-8.6 and I agree that it's pretty odd text now it's been lifted out of that context.
Would it be enough to clarify that this only applies to skipping the consent screen or other similar policies at the AS, but doesn't turn it into a confidential client?
I don't think that's entirely sufficient. As Vittorio noted there's no way for the AS to verify if the url is a claimed https scheme redirect, so this sentence isn't actually actionable:
Measures such as claimed https scheme redirects MAY be accepted by authorization servers as identity proof
I don't know what to suggest. I think what this was trying to say was just a bit of a rewording of the text in https://www.rfc-editor.org/rfc/rfc6749#section-10.2 about using registered redirect urls but adding "https urls are more trustable", but that whole text about registered redirect urls seems not to be there in the equivalent place in OAuth 2.1: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-10.html#section-7.3
From the "Impersonation of native apps" security considerations section:
Vittorio: I find this misleading. Client side measures such as claimed schemes, domains etc might work to prevent an app impersonating another app on the same device/OS, but they aren’t guaranteed to be honored on other operating systems. The AS has no way of knowing whether those measures have been enforced on the client, hence it should not accept them as proof.
Aaron: I believe this was intended to allow the AS to skip the consent screen on repeated authorizations if the app is using a claimed https redirect URI vs a custom scheme. Would it be enough to clarify that this only applies to skipping the consent screen or other similar policies at the AS, but doesn't turn it into a confidential client?