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