I agree that referring to the multiple response_type draft more explicitly is the more helpful thing to do. It will automatically correct any language in the drafts that may be vague on this issue.<div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Sep 4, 2012 at 8:56 AM, 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">
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>
<div class="HOEnZb"><div class="h5"><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>
>>>> --<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>
><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>
</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>