[Openid-specs-ab] Issue #891: New core: unnecessary sentence in 2.3.2.1 (openid/connect)

Nat Sakimura sakimura at gmail.com
Wed Oct 23 10:35:33 UTC 2013


OK but can we stop using the undefined words like implicit flow?

What OAuth has are code and implicit grant and while the "code flow"
in the core maps to code grant, implicit flow does not map to implicit
grant but multiple response types. The "implicit flow" in the core in
fact is the multiple response types that does not have "code" in the
response type, and the hybrid flow is the ones with "code".

=nat via iPhone

On Oct 23, 2013, at 16:05, Roland Hedberg <roland.hedberg at adm.umu.se> wrote:

> +1
>
> 21 okt 2013 kl. 18:36 skrev "Richer, Justin P." <jricher at mitre.org>:
>
>> Nat's got a point about repetition and abstraction, but there's a point where abstractions can end up hurting and I think that the new organization of all three being separate makes more sense to read. It's also in line with what RFC6749 states about the response types: that "foo", "bar", and "foo bar" are all defined separately, with separate semantics and syntax requirements which may or may not overlap.
>>
>> As such, I think we should keep the three separate flows and just be extra diligent about making sure the different portions all line up.
>>
>> -- Justin
>>
>> On Oct 21, 2013, at 12:25 PM, Mike Jones <Michael.Jones at microsoft.com>
>> wrote:
>>
>>> One of the main reasons that Messages and Standard were so confusing *was* that the code flow, the implicit flow, and they hybrid flows were all jammed together, with lots of conditionals in the text that developers had to sort out.  Now the conditionals are gone – instead replaced by 2.1, 2.2, and 2.3.
>>>
>>> The problem with the suggestion that 2.2 and 2.3 be merged is that you’d also have to merge 2.3 into 2.1, because one of the defining characteristics of the hybrid flow is that it uses the Token Endpoint, which is defined in 2.1.  At that point, you’d be back to having all the conditionals we had in Messages and Standard, and we’d lose the value of the reorganization.
>>>
>>>                                                            -- Mike
>>>
>>> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
>>> Sent: Monday, October 21, 2013 9:02 AM
>>> To: George Fletcher
>>> Cc: nov; openid-specs-ab at lists.openid.net
>>> Subject: Re: [Openid-specs-ab] Issue #891: New core: unnecessary sentence in 2.3.2.1 (openid/connect)
>>>
>>> If that is the case, the sentence should read like "No access token is returned when the value is code id_token from the Authorization Endpoint." The access token is returned from the token endpoint in that case.
>>>
>>> The entire "Hybrid Flow" chapter is new, and may need more careful read.
>>> In Messages and Standard, there was nothing called "Hybrid Flow". It was, in a way, combined with other flows.
>>>
>>> Since most of the clauses are actually just pointing to the corresponding sections in the implicit flow, we may as well combine them.
>>> Only the additional things needed would be the code and the c_hash handling and the response from the Token endpoint when the response_type includes 'code'.
>>>
>>> Cheers,
>>>
>>> Nat
>>>
>>>
>>>
>>>
>>> 2013/10/22 George Fletcher <gffletch at aol.com>
>>> I had the same thought... but then also wondered if it was supposed to be "No Access Token is returned when the value is 'code id_token'" as that is one of the allowed response_types and in this case an Access Token would not be returned.
>>>
>>> Thanks,
>>> George
>>>
>>> On 10/21/13 3:16 AM, nov wrote:
>>> New issue 891: New core: unnecessary sentence in 2.3.2.1
>>> https://bitbucket.org/openid/connect/issue/891/new-core-unnecessary-sentence-in-2321
>>>
>>> nov:
>>>
>>> "No Access Token is returned when the value is 'id_token'"
>>>
>>> This sentence shouldnt be needed, since response_type=id_token isn't in the scope of this section.
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>>
>>> --
>>> <image001.png>
>>>
>>> _______________________________________________
>>> 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
>
> -- Roland
> "Education is the path from cocky ignorance to miserable uncertainty.” - Mark Twain
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab


More information about the Openid-specs-ab mailing list