Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Claimed https scheme as app identity proof #141

Open
aaronpk opened this issue Mar 13, 2023 · 1 comment
Open

Claimed https scheme as app identity proof #141

aaronpk opened this issue Mar 13, 2023 · 1 comment
Labels
draft-00-feedback Feedback from reviews of draft -00 interim Items to discuss in the next WG interim meeting

Comments

@aaronpk
Copy link
Member

aaronpk commented Mar 13, 2023

From the "Impersonation of native apps" security considerations section:

Measures such as claimed https scheme redirects MAY be accepted by authorization servers as identity proof. Some operating systems may offer alternative platform-specific identity features that MAY be accepted, as appropriate.

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?

@aaronpk aaronpk added draft-00-feedback Feedback from reviews of draft -00 ietf-116 labels Mar 13, 2023
@aaronpk aaronpk added interim Items to discuss in the next WG interim meeting and removed ietf-116 labels May 11, 2024
@jogu
Copy link

jogu commented May 14, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
draft-00-feedback Feedback from reviews of draft -00 interim Items to discuss in the next WG interim meeting
Projects
None yet
Development

No branches or pull requests

2 participants