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

Torsten Lodderstedt torsten at lodderstedt.net
Thu Oct 17 21:19:35 UTC 2013 

Hi all,

can someone please explain the problems, which shall be resolved by 
POSTing responses? As far as I understand, POSTing responses in OpenID 
2.0 were neccessary in order to transport large amounts of data (esp. 
when utilizing AX). In OAuth and Connect, there is just the authz code + 
state sent to the client in the grant type code. I don't expect them to 
blow up the redirect URI.

regards,
Torsten.

Am 17.10.2013 22:38, schrieb Richer, Justin P.:
> 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 
> <mailto: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
>     <mailto:sakimura at gmail.com>]
>     *Sent:* Thursday, October 17, 2013 9:19 AM
>     *To:* Mike Jones
>     *Cc:* openid-specs-ab at lists.openid.net
>     <mailto: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
>     <mailto: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 <http://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
>     <mailto: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/20131017/3cf0baa3/attachment.html>

More information about the Openid-specs-ab mailing list