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

Torsten Lodderstedt torsten at lodderstedt.net
Thu Oct 17 22:24:44 UTC 2013


HI John,

Am 17.10.2013 23:57, schrieb John Bradley:
> Torsten,
>
> This is not really about the code response type. (Though it might be 
> observed that code to a public client would be safer with POST than 
> GET as the code would not leak in the referrer)
yeah, do you think this is a practical problem? I would assume the 
typical public clients utilizing the code grant type is an native app. I 
don't think they have real issues with HTTP referrers). But we can 
reason about this over a beer at Vancouver :-)

>
> The issue is with the "code id_token", "token id_token", "code token 
> id_token" and "id_token" response types where the recipient is not JS 
> in the browser but a host.
>
> The "code id_token" response type was intended to give the client a 
> fast way to customize the UI while it asynchronously fetches 
> additional data in the back end.
>
> Currently the redirect_uri must contain JS that parses the fragment 
> and sends the contents of the fragment as a form encoded POST to the 
> client.
>
> Some people want to optimize that by having the Authorization server 
> send JS that autoposts a form with the paramaters like openID 2.
>
> There might be a alight speed advantage, but the main advantage is a 
> simpler client (you will now point out that simple clients should use 
> code).

I'm just surprised. I was said some time ago there are people out there, 
who consider processing fragments in JS code and post the result to the 
backend easier than everthing else in the world :-)

Seriously speaking, one can POST the result of the authorization 
transaction to the backend from a OP-provided page. But why would anyone 
want to post both a code as well as tokens to a backend at the same 
time. Does this make any sense to you? One or the other is totally 
sufficient. As you have written above the additional ID/access token was 
intended to "... give the client a fast way to customize the UI while it 
asynchronously fetches additional data in the back end." But if the 
server automatically posts the response to the clients backend there is 
no client UI involved in this process at all. BTW: This also means the 
user experience will be as good or as bad as with HTTP redirects.

>
> The downside to POST in a redirect is well understood as having 
> sub-optimal UI with browser flashing and possibly needing to present a 
> submit button as compared to postMessage or fragment encoding.
>
> My personal feeling is that this is a OAuth issue, though one that 
> impacts Connect.
>

I don't see the issue at all.

> My main concern is forcing something through in Connect may not align 
> with a OAuth WG is that it will require more work for implementers in 
> the long run.
>
> There is nothing in the current spec that is any way unworkable, 
> however using POST can be a useful optimization in some specific 
> environments.
>
> I suspect that this is partially a fragment encoding is new and 
> unfamiliar while POST is well understood by developers issue.
> If everyone moved from fragment to POST for Connect it would not be a 
> positive UI direction.
>
> I have not totally made my mind up yet, but am leaning towards this 
> being a OAuth extension rather than something specific to Connect.

regards,
Torsten.
>
> John B.
>
> On 2013-10-17, at 6:19 PM, Torsten Lodderstedt 
> <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>
>> 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
>>
>> _______________________________________________
>> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131018/4012a2b9/attachment-0001.html>


More information about the Openid-specs-ab mailing list