[Openid-specs-ab] response_type and nonce

Breno de Medeiros breno at google.com
Tue Sep 4 20:09:06 UTC 2012


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


On Tue, Sep 4, 2012 at 12:15 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> 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
> >>>
> >
>
>
> _______________________________________________
> 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/69d62482/attachment.html>


More information about the Openid-specs-ab mailing list