corriganjeff
commented
4 months ago This is an good call out. My thoughts are that this consent paragraph is worthy of it's own section placed outside of the current 9.4. I also do not believe that we should override the OAuth consent MUST you refer to for this spec.
1.) Since it's a first party app and IdP, then maybe we could say that the challenge/response mechanism can include the "consent_required" error code (borrowed from OIDC) as a challenge response to the client. The client MAY automatically respond to this in the affirmative without prompting/notifying the user.
2.) An alternative could be adding an additional request parm to the challenge endpoint to trigger consent suppression. "explicit consent of the resource owner" per 6749 does not need to be a flow interruption. Since it's a first party app this consent can also be provided through EULA/ToS/etc. Performing the consent suppression in this manner would also reduce compute I/O and end user latency because it removes the extra consent challenge/response introduced the previous paragraph.
The problem with both is that consent is also a regulatory requirement. Either option would need to have a call out explaining that how the client and the AS manage consent updates/versioning is out of scope for this spec (e.g. multiple versions of multiple different apps still active).
There could also some form of a consent_version request parm included in both options for what that client currently supports. That would cleanly fit option 2. For option 1 & option 2 there could be a new consent_version_required challenge response to the client. How that versioning reconciliation occurs should be outside the scope of this spec. For example though, the client could update/natively obtain the ability to fulfil requested consent version. If nothing else, both options can default to a webview where existing mechanisms to handle consent can be fulfilled if there is an irreconcilable conflict.
There are very valid first party use cases where it is still appropriate to collect user consent. It's also likely that some of those same use cases in existing platforms have a way to display previously granted consents and allow the user to revoke individual apps/features. This is definitely a topic worthy of its own section no matter what the final text ends up being.
@gffletch @aaronpk thoughts?
aaronpk
Sec. 9.4, the language around consent is hard to parse. Why not say directly that, despite the MUST in RFC 6749, the AS MAY drop the consent screen. (And this is another reason this draft should be updating RFC 6749).