[Openid-specs-ab] response_type and nonce

John Bradley ve7jtb at ve7jtb.com
Tue Sep 4 19:15:50 UTC 2012

With the extended response types the water only gets muddier around what is implicit.  

Perhaps that was what Eran was thinking, that would explain the unauthenticated code flow not being implicit even though it has the same security characteristics.

Best to talk about response_type.

On 2012-09-04, at 4:04 PM, Justin Richer <jricher at mitre.org> wrote:

> On 09/04/2012 02:42 PM, Brian Campbell wrote:
>> FWIW I think implicit was actually intended to mean the grant is
>> implied because there is no grant being exchanged at the token
>> endpoint (see the text I quoted earlier).  Not something about the
>> client identity being implicit.
> For the record, that's the intended interpretation in OAuth2. It took me months of head scratching and several conversations with Eran to get what that was about.
> -- Justin
>> That John and I have different interpretations, however, only
>> underscores the need to not use code/implicit flow and rather be
>> explicit about response types.
>> As I read some things again, I don't think my previous comment about
>> implicit flow -> fragment and code flow -> query works out.
>> Anyway, I do believe this needs to be addressed so I created a rough
>> ticket to track this: https://bitbucket.org/openid/connect/issue/648/
>> On Tue, Sep 4, 2012 at 9:56 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>> Flow in OAuth was more of an artificial thing for structuring the spec examples than a useful distinction.
>>> The Oauth spec uses it to describe the fragment encoded flow.
>>> Though by definition I think it was intended to separate confidential clients from public ones where the client identity is implicit in the registered response URI.
>>> That also covers the code flow for public clients though no one uses the term that way.
>>> I think we are better talking about response_type and token endpoint authentication explicitly.
>>> John B.
>>> On 2012-09-04, at 12:34 PM, Justin Richer <jricher at mitre.org> wrote:
>>>> I agree with this. As stated in the OAuth core, the "flows" are narrowly defined by a combination of the response_type and authorization_grant parameters on the Authorization Endpoint and Token Endpoint, respectively. OpenID Connect has added a whole bunch of extra permutations to the response_type parameter, putting it explicitly outside of the defined "flows". (for better or worse)
>>>> -- Justin
>>>> On 09/04/2012 11:28 AM, Nat Sakimura wrote:
>>>>> We probably should stop using "flows" to describe and refer
>>>>> http://openid.bitbucket.org/oauth-v2-multiple-response-types-1_0.html
>>>>> for the response types.
>>>>> Nat
>>>>> On Tue, Sep 4, 2012 at 8:19 PM, Brian Campbell
>>>>> <bcampbell at pingidentity.com> wrote:
>>>>>> Agreed that there's room for improvement here.
>>>>>> The terms "implicit flow" and "code flow" are used a lot in the
>>>>>> connect suite of specs but are never explicitly defined. The terms do
>>>>>> appear in OAuth but the text there is somewhat at odds with how the
>>>>>> terms are used in Connect.
>>>>>> I.e. on the implicit flow (from 1.3.2):
>>>>>>   "In the implicit flow, instead of issuing the client
>>>>>>    an authorization code, the client is issued an access token directly
>>>>>>    (as the result of the resource owner authorization).  The grant type
>>>>>>    is implicit as no intermediate credentials (such as an authorization
>>>>>>    code) are issued (and later used to obtain an access token)."
>>>>>> So, following from that text, is a response type of code+token really
>>>>>> an implicit flow?
>>>>>> It seems to me (please correct me, if I'm wrong) that when Connect
>>>>>> says "implicit flow" what is meant is any fragment encoded response
>>>>>> and "code flow" means any query string encoded response (though the
>>>>>> "none" response type is kind of an odd man out there). Explicitly
>>>>>> stating that would be helpful in the connect specs and I think it's
>>>>>> worth considering not using the terms "implicit flow" and "code flow"
>>>>>> as the meaning is somewhat overloaded and under defined.
>>>>>> On Mon, Sep 3, 2012 at 5:19 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>>>>>>> Hmm.
>>>>>>> Seems like another ticket item.
>>>>>>> nat
>>>>>>> On Tue, Sep 4, 2012 at 4:27 AM, Roland Hedberg
>>>>>>> <roland.hedberg at adm.umu.se> wrote:
>>>>>>>> John Bradley skrev 2012-09-03 18:13:
>>>>>>>>> id_token on it's own is returned fragment encoded in the front
>>>>>>>>> channel.
>>>>>>>>> The identity of the requester is implicit through the registered
>>>>>>>>> redirect.
>>>>>>>>> Nonce is required in that flow.
>>>>>>>>> The nonce is only not required in the code flow where you are getting
>>>>>>>>> the id_token directly from the token endpoint.
>>>>>>>>> It may be better to say nonce is REQUIRED for all response_type
>>>>>>>>> except the "code" response_type.
>>>>>>>> Absolutely, as it is right now it's open for interpretation which it
>>>>>>>> shouldn't be.
>>>>>>>> _______________________________________________
>>>>>>>> Openid-specs-ab mailing list
>>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>> --
>>>>>>> Nat Sakimura (=nat)
>>>>>>> Chairman, OpenID Foundation
>>>>>>> http://nat.sakimura.org/
>>>>>>> @_nat_en
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-ab mailing list
>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4937 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120904/aadcc4a2/attachment-0001.p7s>

More information about the Openid-specs-ab mailing list