Make authorization_code grant type MTI for PATs and AATs again?

[xmlgrrl]

From discussion in UMA telecon 2014-04-10: In the course of this discussion, we discovered that it was an editing oversight prior to the publication of rev 09 that led to the omission of mentioning authorization_code as an MTI grant type for PAT and AAT support. We could go either way in considering how to fix this: keep it not required, or add it back as a requirement. The authorization_code flow is the most secure, but some environments may not be able to use it. Jin had asked Dick Hardt once what his biggest regret was in OAuth 2, and his answer was the implicit flow. We didn't decide, but started to get a potential preponderance of support for adding back the requirement.

[hisgarden]

Here's some interesting read regarding using OAuth2 Assertion flow and
grant concept overcoming the shortcoming of the implicit flow

http://leastprivilege.com/2013/12/23/advanced-oauth2-assertion-flow-why/

Jin

On Mon, Apr 14, 2014 at 4:41 PM, Eve Maler notifications@github.com wrote:

From discussion in UMA telecon 2014-04-10: In the course of this
discussion, we discovered that it was an editing oversight prior to the
publication of rev 09 that led to the omission of mentioning
authorization_code as an MTI grant type for PAT and AAT support. We could
go either way in considering how to fix this: keep it not required, or add
it back as a requirement. The authorization_code flow is the most secure,
but some environments may not be able to use it. Jin had asked Dick Hardt
once what his biggest regret was in OAuth 2, and his answer was the
implicit flow. We didn't decide, but started to get a potential
preponderance of support for adding back the requirement.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/91
.

Thanks,

Jin

[xmlgrrl]

More thoughts from George's investigations of OpenID Connect's situation wrt MTI grant types, from UMA telecon 2014-04-17: "George looked into the OIDC MTI situation. There are two forms: If you're implementing the protocol in a closed environment (static registration etc.), then there's no requirement for the authorization_code flow. This is in Section 15 of OIDC Core. But if you're implementing it in an open environment (dynamic registration etc.), you're required to implement that flow. Does this speak to what we should do in our spec? Perhaps this tells us that we should make it MTI, since in (say) a single-org environment the deployers are free not to care about achieving conformance, but might end up buying a product that has achieved conformance (by, in part, correctly implementing this flow). Another interpretation would be that the dividing line is simply dynamic registration, which for us is an objective standard because the endpoint must be declared in the config data."

[xmlgrrl]

We agreed on UMA telecon 2014-12-11 that this is not critical for V1.0.

[xmlgrrl]

There is now (in draft UMA 2.0) only a PAT, not an AAT.

Given the variety of use cases expected to be addressed by the UMA Core spec (e.g., traditional web with a human user, API security, and various IoT device flows, with varying sizes of "ecosystem"), does it make sense at this juncture to change from imposing no requirement on authorization servers to imposing one? A profile could always be written to specify a requirement.

[jricher]

We should make interactive OAuth flows (auth code, implicit) RECOMMENDED for the PAT so as to capture the delegation from the RO explicitly. Otherwise it's not in our interests to make a call one way or the other.

[xmlgrrl]

The original purpose of this issue was actually interop, but a lot of water has flowed (um, no pun intended) under the bridge since then.

I think we're probably in pretty good shape with the wording we currently have in Core 2.0 Sec 1.4.1 rev 14, e.g.: "Any OAuth authorization grant type might be appropriate depending on circumstances; for example, the client credentials grant is useful in the case of an organization acting as a resource owner, whereas an interactive grant type is typically more appropriate for capturing the approval of an end-user resource owner."

It's difficult to "hard-prescribe" flows for consent given that we don't know each ecosystem a priori. The implicit grant, assertion grant, etc., all exist for a reason. And as you pointed out, our new AAT-less flow with RqP consent buried somewhere in AS-RqP interactive claims gathering is exactly as strong as our previous AAT-ful flow in terms of prescribing consent on that side.