<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I wasn't saying that there is a problem with the multiple response type registration, more that fitting a response_type of 'code token' neatly into implicit or not gets challenging no matter what Eran originally intended.<div><br></div><div>The term implicit is probably best avoided.</div><div><br></div><div>John</div><div><div><div>On 2012-09-04, at 5:09 PM, Breno de Medeiros <<a href="mailto:breno@google.com">breno@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">The multiple response_type spec was written to comply with the guidelines of the OAuth2 spec re: registering new response_types; since the multiple response_type spec was written there were no fundamental language changes in the OAuth2 spec regarding this issue, AIUI<div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Sep 4, 2012 at 12:15 PM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With the extended response types the water only gets muddier around what is implicit.<br>
<br>
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.<br>
<br>
Best to talk about response_type.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 2012-09-04, at 4:04 PM, Justin Richer <<a href="mailto:jricher@mitre.org">jricher@mitre.org</a>> wrote:<br>
<br>
> On 09/04/2012 02:42 PM, Brian Campbell wrote:<br>
>> FWIW I think implicit was actually intended to mean the grant is<br>
>> implied because there is no grant being exchanged at the token<br>
>> endpoint (see the text I quoted earlier). Not something about the<br>
>> client identity being implicit.<br>
> 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.<br>
><br>
> -- Justin<br>
><br>
>><br>
>> That John and I have different interpretations, however, only<br>
>> underscores the need to not use code/implicit flow and rather be<br>
>> explicit about response types.<br>
>><br>
>> As I read some things again, I don't think my previous comment about<br>
>> implicit flow -> fragment and code flow -> query works out.<br>
>><br>
>> Anyway, I do believe this needs to be addressed so I created a rough<br>
>> ticket to track this: <a href="https://bitbucket.org/openid/connect/issue/648/" target="_blank">https://bitbucket.org/openid/connect/issue/648/</a><br>
>><br>
>><br>
>> On Tue, Sep 4, 2012 at 9:56 AM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<br>
>>> Flow in OAuth was more of an artificial thing for structuring the spec examples than a useful distinction.<br>
>>><br>
>>> The Oauth spec uses it to describe the fragment encoded flow.<br>
>>><br>
>>> 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.<br>
>>> That also covers the code flow for public clients though no one uses the term that way.<br>
>>><br>
>>> I think we are better talking about response_type and token endpoint authentication explicitly.<br>
>>><br>
>>> John B.<br>
>>><br>
>>><br>
>>> On 2012-09-04, at 12:34 PM, Justin Richer <<a href="mailto:jricher@mitre.org">jricher@mitre.org</a>> wrote:<br>
>>><br>
>>>> 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)<br>
>>>><br>
>>>> -- Justin<br>
>>>><br>
>>>> On 09/04/2012 11:28 AM, Nat Sakimura wrote:<br>
>>>>> We probably should stop using "flows" to describe and refer<br>
>>>>> <a href="http://openid.bitbucket.org/oauth-v2-multiple-response-types-1_0.html" target="_blank">http://openid.bitbucket.org/oauth-v2-multiple-response-types-1_0.html</a><br>
>>>>> for the response types.<br>
>>>>><br>
>>>>> Nat<br>
>>>>><br>
>>>>> On Tue, Sep 4, 2012 at 8:19 PM, Brian Campbell<br>
>>>>> <<a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>> wrote:<br>
>>>>>> Agreed that there's room for improvement here.<br>
>>>>>><br>
>>>>>> The terms "implicit flow" and "code flow" are used a lot in the<br>
>>>>>> connect suite of specs but are never explicitly defined. The terms do<br>
>>>>>> appear in OAuth but the text there is somewhat at odds with how the<br>
>>>>>> terms are used in Connect.<br>
>>>>>><br>
>>>>>> I.e. on the implicit flow (from 1.3.2):<br>
>>>>>><br>
>>>>>> "In the implicit flow, instead of issuing the client<br>
>>>>>> an authorization code, the client is issued an access token directly<br>
>>>>>> (as the result of the resource owner authorization). The grant type<br>
>>>>>> is implicit as no intermediate credentials (such as an authorization<br>
>>>>>> code) are issued (and later used to obtain an access token)."<br>
>>>>>><br>
>>>>>> So, following from that text, is a response type of code+token really<br>
>>>>>> an implicit flow?<br>
>>>>>><br>
>>>>>> It seems to me (please correct me, if I'm wrong) that when Connect<br>
>>>>>> says "implicit flow" what is meant is any fragment encoded response<br>
>>>>>> and "code flow" means any query string encoded response (though the<br>
>>>>>> "none" response type is kind of an odd man out there). Explicitly<br>
>>>>>> stating that would be helpful in the connect specs and I think it's<br>
>>>>>> worth considering not using the terms "implicit flow" and "code flow"<br>
>>>>>> as the meaning is somewhat overloaded and under defined.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> On Mon, Sep 3, 2012 at 5:19 PM, Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>> wrote:<br>
>>>>>>> Hmm.<br>
>>>>>>><br>
>>>>>>> Seems like another ticket item.<br>
>>>>>>><br>
>>>>>>> nat<br>
>>>>>>><br>
>>>>>>> On Tue, Sep 4, 2012 at 4:27 AM, Roland Hedberg<br>
>>>>>>> <<a href="mailto:roland.hedberg@adm.umu.se">roland.hedberg@adm.umu.se</a>> wrote:<br>
>>>>>>>> John Bradley skrev 2012-09-03 18:13:<br>
>>>>>>>>> id_token on it's own is returned fragment encoded in the front<br>
>>>>>>>>> channel.<br>
>>>>>>>>><br>
>>>>>>>>> The identity of the requester is implicit through the registered<br>
>>>>>>>>> redirect.<br>
>>>>>>>>><br>
>>>>>>>>> Nonce is required in that flow.<br>
>>>>>>>>><br>
>>>>>>>>> The nonce is only not required in the code flow where you are getting<br>
>>>>>>>>> the id_token directly from the token endpoint.<br>
>>>>>>>>><br>
>>>>>>>>> It may be better to say nonce is REQUIRED for all response_type<br>
>>>>>>>>> except the "code" response_type.<br>
>>>>>>>> Absolutely, as it is right now it's open for interpretation which it<br>
>>>>>>>> shouldn't be.<br>
>>>>>>>> _______________________________________________<br>
>>>>>>>> Openid-specs-ab mailing list<br>
>>>>>>>> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
>>>>>>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>>>>>>><br>
>>>>>>> --<br>
>>>>>>> Nat Sakimura (=nat)<br>
>>>>>>> Chairman, OpenID Foundation<br>
>>>>>>> <a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
>>>>>>> @_nat_en<br>
>>>>>>> _______________________________________________<br>
>>>>>>> Openid-specs-ab mailing list<br>
>>>>>>> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
>>>>>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>>>>><br>
>>>> _______________________________________________<br>
>>>> Openid-specs-ab mailing list<br>
>>>> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
>>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>>><br>
>>> _______________________________________________<br>
>>> Openid-specs-ab mailing list<br>
>>> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>>><br>
><br>
<br>
</div></div><br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>--Breno<br><br>
</div>
</blockquote></div><br></div></body></html>