[Openid-specs-ab] response_type and nonce

Breno de Medeiros breno at google.com
Tue Sep 4 17:26:32 UTC 2012


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.


On Tue, Sep 4, 2012 at 8: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
>
>


-- 
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120904/1b8155fc/attachment-0001.html>


More information about the Openid-specs-ab mailing list