Re: [OAUTH-WG] Confusion on Implicit Grant flow

John Bradley <ve7jtb@ve7jtb.com> Tue, 10 February 2015 14:01 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538421A026E for <oauth@ietfa.amsl.com>; Tue, 10 Feb 2015 06:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdGRIsJrPx0P for <oauth@ietfa.amsl.com>; Tue, 10 Feb 2015 06:01:09 -0800 (PST)
Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C097B1A02F1 for <oauth@ietf.org>; Tue, 10 Feb 2015 06:01:08 -0800 (PST)
Received: by mail-qg0-f54.google.com with SMTP id z60so26236582qgd.13 for <oauth@ietf.org>; Tue, 10 Feb 2015 06:01:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8/LWdr3pfiBIflD/Vksg45CyF8xA8rqmY/kNi12VAsQ=; b=WcxcPfvRnA4Xg93ZON8tSgfrFfXllZACEP3T/VzQA5EE6pbAgqK/trDAtt5zQdvwHC /4pBJw+MMUOYXV7kSpPy41z7IxcwOUTyZGylbUNmrCSyxpTeLFQ3EmbFEWfeSOn7B0hm tagW/QEDQuUvJE+QHrcBqIp+kBPGcuIj2YVtujcZJfzQuc4ciep2NQ79fzVBh1TTRBVF eCsVOdqSjMhjXjKntldFmQKtViPjjKXl6g/AtQaF5+hOxBOX+aVh7NrnVQGPEMDkNTFy VSucq/YuI8WRy/YEr9tXaIm8eIAkwRwY1uya+kc95VaFlsTbhhk8X0jS/HEVbHt9zwB1 dLEA==
X-Gm-Message-State: ALoCoQlsxCRU6j2g5TNQJmHDxMfCkP/cq0vTxzacSpREPFQY103khqYmd1qcW+MzRvM+pGTOcH9W
X-Received: by 10.224.127.6 with SMTP id e6mr41265480qas.42.1423576866960; Tue, 10 Feb 2015 06:01:06 -0800 (PST)
Received: from [192.168.8.101] ([181.202.146.189]) by mx.google.com with ESMTPSA id l93sm15266195qgd.23.2015.02.10.06.01.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Feb 2015 06:01:06 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_FE77C8A0-2E9F-4F91-995A-DDAB8E3CC2D7"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <54DA090B.1010107@redhat.com>
Date: Tue, 10 Feb 2015 11:00:59 -0300
Message-Id: <CF5E0308-A072-447F-9703-1F1D40F3DF00@ve7jtb.com>
References: <BLUPR04MB6918C7701D0DB90B0FA6B0D95380@BLUPR04MB691.namprd04.prod.outlook.com> <CANSMLKFMUQsBfOo=i0ki8PF_8PjRf7W3t=PiPo7qnftN9gUyWg@mail.gmail.com> <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com> <FD337176-C292-4688-9CFA-A3C7DF40FCA2@ve7jtb.com> <54D92A3C.4060106@redhat.com> <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com> <54D93578.9050105@redhat.com> <61E85A1A-E52C-4709-A1A4-791E4141B8B1@ve7jtb.com> <CA+k3eCSvm41d3ChDqWnnzsxKUbRewYVHDPyP-0xW_kaRDs+T5w@mail.gmail.com> <54DA090B.1010107@redhat.com>
To: Bill Burke <bburke@redhat.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/WiuEvYhuuehuLAeLRjLeZkyy5kU>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Feb 2015 14:01:13 -0000

The code and implicit response_type are defined in RFC 6749.  
https://tools.ietf.org/html/rfc6749#section-4.1.2
https://tools.ietf.org/html/rfc6749#section-4.2.2

It describes one way to encode the response in each case with no mention of that being extended.   In the text there is no normative MUST.

I personally think changing the encoding of code via response_mode might be a technical violation of RFC 6749,  it will defiantly cause interop problems.

The multiple response type spec restates the defaults from RFC 6749, but doesn't explicitly say that you can change them with response_mode.

In Connect we were careful not to override anything in RFC 6749.

In your deployment using response_mode with code might work perfectly fine.  
Interop problems by implementations not expecting response_mode with the code response_type are the only real concern.

John B.


> On Feb 10, 2015, at 10:35 AM, Bill Burke <bburke@redhat.com> wrote:
> 
> 
> 
> On 2/10/2015 7:06 AM, Brian Campbell wrote:
>> 
>> 
>> On Mon, Feb 9, 2015 at 3:59 PM, John Bradley <ve7jtb@ve7jtb.com
>> <mailto:ve7jtb@ve7jtb.com>> wrote:
>> 
>>    Connect has a response_mode that allows the response to be form
>>    encoded rather than fragment.
>>    I read RFC 5849 as only allowing code to be query encoded.   The
>>    response_mode was intended for the new response types we defined in
>>    http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>> 
>> 
>> Actually response_mode is defined in that spec itself in section 2.1
>> <http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#ResponseModes>.
>> 
> 
> Yeah, and it looks like you can use it for anything.  It only defines default modes for various response types (code, token, etc.)
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com