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

hideki nara hdknr at ic-tact.co.jp
Fri Oct 18 00:23:30 UTC 2013


I'm with Justin 100%.

We should invest enough time to discuss in another extension spec
and feel happy each other.

---
hideki


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

>  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] *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
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131018/bbcb7676/attachment-0001.html>


More information about the Openid-specs-ab mailing list