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

Torsten Lodderstedt torsten at lodderstedt.net
Mon Oct 21 16:17:43 UTC 2013


+1

This is a complete new flow. It does not replace or modify the fragment-based stuff.



Nat Sakimura <sakimura at gmail.com> schrieb:
>+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
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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/20131021/f46c4789/attachment-0001.html>


More information about the Openid-specs-ab mailing list