Some additional input From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, April 21, 2011 12:28 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] Revised Section 3
This got a little bit too nested so I kept only the comments where we are not on the same page. From: Anthony Nadalin <tony...@microsoft.com<mailto:tony...@microsoft.com>> Date: Thu, 21 Apr 2011 11:34:32 -0700 To: Eran Hammer-lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>>, Dick Hardt <dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>> The 'assertion' grant type has been replaced with a more generic extension mechanism. Basically, we combined the 'grant_type' and 'assertion_type' parameters into a single extension point. So what was previously sent like this: grant_type=assertion&assertion_type=http://some.assertion.type.uri Is now send as: grant_type=http://some.assertion.type.uri This change was made in -12 with WG consensus. At the time, the 'assertion' parameter was relocated to the SAML draft. AJN -> OK, my mistake but still causes issues Can you please explain what issues this change causes? There is currently no open issue regarding this change, and it has nothing to do with this thread. AJN-> just an issue for the use case that we have as this does not allow for the usage of 2 assertions, not a new issue An extension grant type (which is the mechanism used by the SAML draft) will not be suitable here. This use care requires defining a new way to authentication HTTP requests (traditional client authentication) using assertions, similar to how Basic is used to authenticate requests using a username and password. AJN -> This is maybe where we differ, as taking revised section 3 solves the problem We agree here that the grant type extension mechanism does not address this use case (which was Dick's question to you). The proposed section adds a new extensibility point which does address the use case. We disagree on the details of that proposal, but we agree that it does address the use case. Also, it doesn't matter if the new text doesn't set to define a new general purpose HTTP client authentication scheme using assertions. In practice, that's what it is creating. You can view it from the narrow perspective of the v2 specification, but in practice, deploying this client assertion credentials method means deploying a new HTTP authentication scheme. For example, an authorization server supporting both client password credentials using HTTP Basic and this assertion alternative, will probably want to implement both at the same layer. This means that even though the assertion route does not use the HTTP authorization header, the web server will still extract those form-encoded parameter at the same place it does Basic. Otherwise you perform the same functionality (authenticating a client) at different places which for many, is not a proper architecture. This is all philosophical about the big picture implications of what the new assertion authentication proposal does, but it is important when done in the context of an IETF standard. Much of my criticism and objections to the proposed solution and text are coming out of my view that this is not a proper way and place to define a new HTTP authentication scheme. Since our charter is useless at this point, I have refrained from bringing up the fact that defining a new HTTP authentication scheme using assertions is out of scope. But since the chairs are now working on fixing the charter to reflect reality, I guess they will need to directly address this specific use case. Everything in -15 is implicitly in scope because it directly originates from OAuth 1.0 and WRAP. This is completely new. AJN-> So the client credentials originate from WRAP also, it's not completely new, it may be new the way that it got worded but the same functionality was in WRAP. The section 5.2 (and subsections) in the WAP specification is where you see the assertion documented but what is not explicitly stated (other than additional parameters clause)there but not disallowed is the ability to have the access_token (additional parameters) also specified so you were allowed to have 2 assertions in WRAP for authentication Adding 4.4.3-like text to 4.5 does not have *any* normative implications. Section 4.5 provides an extension point to the token endpoint. Section 4.4.3 merely states the obvious in how responses to token requests are handled. Adding it will be done purely for clarity. AJN -> OK, as long as it is not normative It is already normative - this is just clarifying it. Section 4.5 is an extension of the access token endpoint. All responses to the access token endpoint must comply with section 5. Adding a 4.4.3-like text merely states that. You cannot define a new grant type per 4.5 that does not comply with the normative text of section 5. If this is a problem (which means it is a problem in -15 already), please open a new issue. AJN-> I need to think on this and make sure we don't have a case where the extension would not return what is in th base So I agree that the current specification doesn't address the use case of using an assertion to authenticate the client. Beyond that we disagree on everything else related to how to address it. AJN -> Agree, and maybe we don't agree that this is a problem to be solved? We agree it is a problem and that since you want to deploy this use case, a solution is required. I don't have anything against the use case. However, I don't think this WG or the v2 specification are the right place to address it. EHL
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
