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

Vladimir Dzhuvinov / NimbusDS vladimir at nimbusds.com
Tue Oct 22 07:06:52 UTC 2013


+1, I also find the approach of RFC 6749 to have each flow described
individually better.

--
Vladimir Dzhuvinov : www.NimbusDS.com : vladimir at nimbusds.com


-------- Original Message --------
Subject: Re: [Openid-specs-ab] Issue #891: New core: unnecessary
sentence in 2.3.2.1 (openid/connect)
From: "Richer, Justin P." <jricher at mitre.org>
Date: Mon, October 21, 2013 5:36 pm
To: Mike Jones <Michael.Jones at microsoft.com>
Cc: "openid-specs-ab at lists.openid.net Group"
<openid-specs-ab at lists.openid.net>

 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


More information about the Openid-specs-ab mailing list