[Openid-specs-ab] Spec call notes 17-Oct-13

Nat Sakimura sakimura at gmail.com
Mon Oct 21 15:34:49 UTC 2013


+1


2013/10/22 Richer, Justin P. <jricher at mitre.org>

>  I would agree with you if the spec were broken, but it isn't. This isn't
> a fix, it's an extension and introduction of functionality and should be
> treated as such.
>
>  For what it's worth, now that I've had a chance to read through more of
> the threads, I'm fine with Mike's approach of leaving necessary extension
> points in core and defining them fully in an extension that can dig out all
> the appropriate behaviors and considerations.
>
>   -- Justin
>
>  On Oct 21, 2013, at 2:09 AM, Anthony Nadalin <tonynad at microsoft.com>
> wrote:
>
>   -1****
>
>  fixing specifications is in scope at any stage****
>
>   *From:* Richer, Justin P. [mailto:jricher at mitre.org]
> *Sent:* Sunday, October 20, 2013 10:57 PM
> *To:* Mike Jones
> *Cc:* Anthony Nadalin; Nat Sakimura; openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Spec call notes 17-Oct-13****
>   ** **
>  There's a very big difference between adding an optional parameter that
> clarifies the presumably-intended parallelism between two parts of the spec
> suite (registration and discovery) and something which adds a completely
> new flow and response type with all the requisite processing, security
> considerations, and other matters that haven't been sorted out. Especially
> when the details are apparently not very clear, from what I can see from
> other discussion on the list about this. ****
>  ** **
>   In my opinion, adding a feature this deep at this stage of the process
> makes no sense. Add it as an extension that defines the new flow in context
> or save it for version 3.1.****
>   ** **
>    -- Justin****
>  ** **
>   ** **
>   On Oct 17, 2013, at 5:36 PM, Mike Jones <Michael.Jones at microsoft.com>***
> *
>    wrote:****
>
>
> ****
>
>  There’s no sneaking going on here, any more than there was to add
> “token_endpoint_auth_signing_alg” for issue #875 (which I know you were in
> favor of, even though it was also a late addition).****
>    ****
>   There’s no mystery why this came up now.  As discussed on Monday’s and
> today’s calls, during interop testing with Microsoft’s current
> implementation, we discovered that the developers were returning the ID
> Token as a query parameter when using the “code id_token” flow, because
> it’s easier for relying parties to code to than having to write JavaScript
> to handle the fragment and post the result back to an internal site.  In
> response, we changed Multiple Response Types earlier this week to
> explicitly prohibit this and communicated that back to the team here.  They
> asked for a POST binding instead, because it’s also easier than the
> fragment handling, and because they already have code to handle this for
> both SAML and WS-Federation.  It was odd to them that we didn’t have this
> alternative in OpenID Connect (which we do in OpenID 2.0, by the way).****
>    ****
>   At first I pushed back, but when I realized that Ping also already had
> this feature and that Google isn’t using the fragment encoding either, I
> started to agree that this made sense.  So I brought it up on the call and
> agreed to write up proposed text.****
>    ****
>   Nothing Machiavellian going on, any more than there was with #875.
> Hopefully you’ll review the proposed text when it comes out.  I think
> you’ll find that it’s pretty straightforward.  (If it wasn’t
> straightforward, I wouldn’t be advocating it.)****
>    ****
>                                                               -- Mike****
>    ****
>   *From:* Richer, Justin P. [mailto:jricher at mitre.org]
> *Sent:* Thursday, October 17, 2013 1:38 PM
> *To:* Anthony Nadalin; Nat Sakimura; Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* RE: [Openid-specs-ab] Spec call notes 17-Oct-13****
>    ****
>
> I completely agree with Nat. There have been many months for people to
> comment on, interop with, and add features to the set. I think that
> changing something this fundamental this late in the game with so little
> testing behind it is ludicrous. I don't understand how this is coming up
> all of a sudden. From my perspective, it sounds like one contingent is
> trying to sneak something in just under the wire and hoping nobody will
> notice.
>
> This can easily be defined as an extension and it would do much more harm
> than good trying to cram it in now.
>
> As to Tony's contention: plenty of us are deploying and exactly what you
> keep calling impossible. There are numerous existence proofs in contrast to
> your position.
>
>  -- Justin****
>  ------------------------------
>
> *From:* openid-specs-ab-bounces at lists.openid.net [
> openid-specs-ab-bounces at lists.openid.net] on behalf of Anthony Nadalin [
> tonynad at microsoft.com]
> *Sent:* Thursday, October 17, 2013 2:04 PM
> *To:* Nat Sakimura; Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Spec call notes 17-Oct-13****
>   If you can’t deploy this stuff it’s no good, it would then be a board
> issue to approve or disapprove and I know where I would vote****
>    ****
>   *From:* openid-specs-ab-bounces at lists.openid.net [
> mailto:openid-specs-ab-bounces at lists.openid.net<openid-specs-ab-bounces at lists.openid.net>
> ] *On Behalf Of *Nat Sakimura
> *Sent:* Thursday, October 17, 2013 9:55 AM
> *To:* Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Spec call notes 17-Oct-13****
>    ****
>   I completely disagree. We have feature frozen months ago and we should
> not allow any feature bloat now. We have decided it and we must adhere to
> it. ****
>   It is a process and trust issue. Also, the timing is critical for
> several things that you probably have already heard. ****
>    ****
>   If it could not be done with an extension, I would be more sympathetic.
> However, in this case, you can do it as an extension, and that is still
> conformant once that extension gets voted. The core does not prohibit it.
> ****
>    ****
>   And do not mix up Google's postMessage and Form encoding + POSTing. ****
>   The fragment encoding was supposed to be used with postMessage and
> that's what Google is doing. ****
>    ****
>   Even if you had the new feature text on Monday, there is not enough
> review period. ****
>   Also, note that the Monday meeting has no authority to decide on such
> things. It has to be done in the list, and we have to give ample time to
> respond. ****
>    ****
>   We MUST NOT push any new feature through so quickly. ****
>    ****
>   Sorry to be a process police here, but that's what I have to do as a
> chair. ****
>
>  ****
>   2013/10/18 Mike Jones <Michael.Jones at microsoft.com>****
>
>  I actually think that getting the features right, such that developers
> will actually use what’s in the spec, rather than do something
> non-conformant, is more important than a few days of schedule.****
>    ****
>   It’s pretty telling that Google, Ping, and Microsoft all are using
> something other than fragment encoding in some cases for Implicit/Hybrid
> flows.  Far better to enable interop on these non-fragment return types
> than have everyone do something outside the spec.****
>    ****
>   As we said on the call, I’ll write up a concrete proposal so people can
> review it in advance of Monday.****
>    ****
>   Yes, we’re late in the process, but far better to make a late addition
> than to ship something that we know has defects that will cause people to
> do things not in the spec.****
>    ****
>                                                               -- Mike****
>    ****
>   *From:* Nat Sakimura [mailto:sakimura at gmail.com]
> *Sent:* Thursday, October 17, 2013 9:19 AM
> *To:* Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Spec call notes 17-Oct-13****
>    ****
>   Please add to the note that Nat has pointed out that this is not the
> time to add a new feature that it can and should be dealt with extension.
> ****
>    ****
>   Also, John has pointed out that expanding the feature will cause
> interoperability problems. ****
>    ****
>   As part of the AOL's OpenID 2.0 provider explanation, it was pointed
> out that the UI would show flash and button, and that was the reason we
> have dropped it from the current Connect spec. ****
>   In fact, not only AOL but many others did it in OpenID 2.0 as that was
> the only option, and it was also something that many of us wanted to escape
> from. ****
>    ****
>   The reason sited in support of form POSTing were as follows: ****
>    ****
>   1) It is done by SAML and WS. ****
>   2) Fragment would not be able to hold large payload. ****
>   3) If it is not there, implementers will do stupid things like
> including access token in the query parameter. ****
>   4) If the browser is not Javascript enabled, it is the last resort. ****
>    ****
>   In the above, 1) does not make sense. The web technology has advanced
> so much since they were designed. We have considered the option previously
> and dropped. ****
>   As to 2) is concerned, the statement is false. Fragment can hold pretty
> big payload. It was tested during the self-issued testing, and we found out
> that the limit is actually pretty large. We were sending photos as a claim
> in id_token as a result of it. (Note: I need to double check - since we
> were concerned mostly on mobile platform, we may not have tested IE.) ****
>   The reason 3) is not a good one either. We should just write an
> implementers NOTE that they should never do this. ****
>   As a result, only the credible reason is 4). However, this means that a
> lot of other things at the destination site will break, too. ****
>    ****
>   I understand that there are people who want to do it. ****
>   Even some of NRI's internal developers wants to do it. ****
>   However, that is not a good enough reason to get it into the core at
> this point in time. ****
>   In addition, there will be bunch of moving parts that we have to fix if
> we were to do it. ****
>   We should not do it in three days. We should take more time to consider
> various implications. ****
>   We are finalizing the core spec now. The cut off date is end of this
> week. ****
>    ****
>   It should be done as an extension. I oppose to do it in the core. ****
>   Our priority to get the Core out of the door, now. ****
>    ****
>
>  ****
>   2013/10/17 Mike Jones <Michael.Jones at microsoft.com>****
>   Spec call notes 17-Oct-13****
>    ****
>   Mike Jones****
>   Brian Campbell****
>   George Fletcher****
>   John Bradley****
>   Nat Sakimura****
>   Edmund Jay****
>    ****
>   Agenda:****
>                  Open Issues****
>                  Multiple response type requests returning values in ways
> other than fragments****
>                  Document Restructuring and Review****
>    ****
>   Open Issues:****
>                  #873: session 4.1. Can we use opbs with http (not
> httponly)****
>                                 We developed proposed text for this****
>                  #879 & #880: Hosting self-issued.me****
>                                 John will get the cheapest Amazon VM and
> give Edmund access to it****
>    ****
>   Multiple response type requests returning values in ways other than
> fragments****
>                  Microsoft has asked for a POST binding, like
> WS-Federation and SAML have****
>                  Ping has an extra response_type component x_post****
>                                 This causes the responses to POST to be
> returned as form-encoded body content****
>                  Google has a way of registering clients to use a
> postMessage binding****
>                                 They do that by registering a JavaScript
> origin, rather than response_type****
>                  AOL's OpenID 2.0 provider often uses the POST response
> because of large AX responses****
>                  John had proposed a registration parameter for this:****
>                                 redirect_type   fragment | POST |
> postMessage****
>                  This would be discoverable as****
>                                 redirect_types_supported****
>                  Another reason for this is to not hit fragment size
> limits****
>                  Mike will file a bug on this to make a concrete proposal*
> ***
>                  We will discuss this at the Monday meeting****
>    ****
>   Document Restructuring and Review:****
>                  Mike posted a Word version of the Core spec with tracked
> changes turned on****
>                                 People are requested to mark it up with
> specific proposed changes this week****
>
>
> _______________________________________________
> 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****
>
>
>
> ****
>    ****
>   --
> Nat Sakimura (=nat)****
>   Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131022/f6733e9e/attachment-0001.html>


More information about the Openid-specs-ab mailing list