[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.html>
More information about the Openid-specs-ab
mailing list