Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

[Breno de Medeiros <[e-mail]>]

Can you explain to me why response_type is necessary at all after this change.

If a javascript client (candidate for token usage) and the web server
component (candidate for code usage) cannot share registration (since
they are different components with different security contexts of the
same application) then there is no need to specify response_type. The
server can infer the response type from the client and its security
context.

My objection has nothing to do with code+token flow. I think the
change makes response_types irrelevant and is essentially a new
protocol.

As far as I understand it, the introduction of different code and
token flows was precisely to allow different security-context
components of the same client to securely operate under the same
registration. I think if we change this we need to specify a lot more
behavior, such as how a client can request authorization on behalf of
several components simultaneously.

On Wed, Mar 14, 2012 at 10:08, Eran Hammer <[e-mail]> wrote:
> This was already raised and addressed on this list last week.
>
> When someone defines and registers code+token, that specification must define how such a client is registered in light of the text below. This might mean defining a new client type, choosing the confidential client type with other normative text limiting the use of the secret in the public component, etc.
>
> IOW, this section doesn't break anything because there is nothing else defined to break. There is no way to avoid explicitly defining these requirements for a code+token response type, or any other new response type for that matter. The text below is required to ensure that the authorization server can properly enforce the rest of the normative security language in the specification.
>
> EH
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Marius Scurtescu
>> Sent: Wednesday, March 14, 2012 9:53 AM
>> To: OAuth WG
>> Cc: Breno de Medeiros
>> Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
>>
>> Hi,
>>
>> Nat Sakimura started a thread on the OpenID Connect list about a breaking
>> change introduced by rev 2.3
>>
>> The paragraph in question is in section 2.1:
>>
>> "A client application consisting of multiple components, each with its own
>> client type (e.g. a distributed client with both a confidential server-based
>> component and a public browser-based component), MUST register each
>> component separately as a different client to ensure proper handling by the
>> authorization server.  The authorization server MAY provider tools to manage
>> such complex clients through a single administration interface."
>>
>> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-oauth-v2-
>> 23.txt
>>
>> You can see the thread here:
>> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-
>> 20120312/001672.html
>>
>> This paragraph basically prevents response_type=code+token which is
>> already implemented by many providers and also relied on by OpenID
>> Connect.
>>
>> The intent, I think, was to prevent clients from embedding the client secret
>> meant for a confidential client into a public client.
>> JavaScript based clients using the token flow do not need the client secret, so
>> this concern does not apply.
>>
>> Thoughts?
>>
>> Thanks,
>> Marius
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth



-- 
--Breno