[Openid-specs-ab] Complete set of proposed changings enabling form_post response encoding

Brian Campbell bcampbell at pingidentity.com
Sat Oct 19 13:39:53 UTC 2013


+1 to language in core etc. that **permits** such bindings to be specified
and used now or in the future.

While it's clear that the WG plans to use a new parameter (i.e.
response_mode) rather than new response type(s) [1], I'd respectfully
request that language in core etc. not explicitly prohibit that approach
either. I don't believe the drafts prohibited it at the time we did it and
I view it as a perfectly reasonable and legal extension aimed at the same
goal as the response_mode=form_post. We will, of course, update our
implementations to use the standardized method once it's accepted. However,
we'll need to support our existing way of doing it for some time and want
to avoid any unnecessary stigma for being non compliant. And there may well
be unforeseen but legitimate response type extensions in the future that
should be permitted.

[1]
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20131014/004063.html


On Fri, Oct 18, 2013 at 7:52 PM, Mike Jones <Michael.Jones at microsoft.com>wrote:

>  Full HTML versions****
>
>
> http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-18-Oct-13.html
> ****
>
>
> http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13.html**
> **
>
>
> http://self-issued.info/docs/openid-connect-core-1_0-18-Oct-13.html****
>
> ** **
>
> Word versions showing diffs from Bitbucket versions:****
>
>
> http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-18-Oct-13-diffs.docx
> ****
>
>
> http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13-diffs.docx
> ****
>
>
> http://self-issued.info/docs/openid-connect-core-1_0-18-Oct-13-diffs.docx*
> ***
>
> ** **
>
> Status updates:  Multiple Response Types now uses the Response Mode
> identifier “form_post” (rather than “POST”) and specifies the use of the
> application/x-www-form-urlencoded encoding for the form posted responses.
> Discovery includes the “response_modes_supported” parameter.  In Core,
> rather than saying things like “MUST be fragment encoded” we now say things
> like “MUST be fragment encoded, unless a different Response Mode was
> specified”.****
>
> ** **
>
> As for where we go from here, from George’s proposal and Nat’s +1 to it, I
> believe that the only part of these proposed changes that there’s still
> active debate about is whether the “form_post” Response Mode should be
> defined as an extension to Multiple Response Types or in Multiple Response
> Types itself.  Even those who are skeptical of trying to include the new
> binding as a final part of the specs appear to agree that we’re right to
> generalize the language in Core, etc. to **permit** such bindings to be
> specified and used in the future – which is what’s really been done in Core
> and Discovery and in all of the Multiple Response Types changes other than
> the subsections that actually define the new Response Mode.****
>
> ** **
>
> I’m saying that, because given that as editor, I now already have numerous
> feedback comments to incorporate (thanks Vladimir and Torsten!), and I plan
> to start incorporating them tomorrow.  Unless I hear serious objections to
> proceeding in this manner, I plan to check in the sources to the above and
> make the changes against those versions.  I recognize that if “form_post”
> becomes a separate extension, that means I’d need to separate it from
> Multiple Response Types.  That’s not hard.  However, I believe that all the
> other changes, which **enable but do not define** alternative Response
> Modes, would stay.  It will be much easier for me as editor to work that
> way, rather than maintaining two sets of change branches and merging them
> later.  (This matters because our time is short – especially the time
> before Monday’s meeting.)****
>
> ** **
>
> Thanks for the vigorous discussion the past few days and for all of your
> demonstrated passion both for finishing and for a high quality outcome.
> Keep those spec reviews coming!****
>
> ** **
>
>                                                             Cheers,****
>
>                                                             -- Mike****
>
> _______________________________________________
> 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/20131019/f4b03c2c/attachment.html>


More information about the Openid-specs-ab mailing list