[Openid-specs-ab] proposed POST response type for OAuth/Connect

Breno de Medeiros breno at google.com
Thu Oct 17 23:01:36 UTC 2013


On Thu, Oct 17, 2013 at 11:37 AM, Mike Jones <Michael.Jones at microsoft.com>wrote:

>  Thanks, Brian.  This is really useful.  I suspect I’ll be using some of
> your text in my write-up. J****
>
> ** **
>
> I just spent some time on the phone with Breno discussing this and he
> agreed that defining a POST response at this point is reasonable.  When
> talking about possible ways of specifying the POST response behavior, he
> stated the principle that when a behavioral change is being requested, that
> this should be done so dynamically, rather than via registration.  That
> way, particular clients can be updated to use this behavior without
> requiring a new client registration.  (He likes using registration to
> specify behavioral restrictions, however, such as requiring particular
> signing/encryption algorithms, etc.)****
>
> ** **
>
> He said that the way that he’d do it is to include a “transport=POST”
> parameter in the authorization request.  So that’s what I’ll write up.  We
> could later than define “transport=postMessage”, “transport=CORS”, etc. if
> we decide to do so.
>

I think this is sufficiently small that we might be able to undertake in a
short time-frame. I believe that POST support will prove useful. I'd
recommend this to be added to the new response types part of the spec:
http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html, for a
number of reasons: It already has the burden to deal with the security
properties of different encoding formats for different response types, and
would be a small change in scope to change it to talk about 'transport'
modes instead of encoding. That spec also has been stable and changed
little for a long time, so the chance that it can be re-written w/o
side-effects is probably higher.




> ****
>
> ** **
>
> As an aside, Breno also said that the reason that he thinks Session
> Management isn’t yet ready to be final, is that he’d like us to explore the
> option of using a CORS transport, rather than postMessage within Session
> Management.  I’ll leave it to Breno to say more about this.****
>
> ** **
>
>                                                                 Thanks all,
> ****
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* openid-specs-ab-bounces at lists.openid.net [mailto:
> openid-specs-ab-bounces at lists.openid.net] *On Behalf Of *Brian Campbell
> *Sent:* Thursday, October 17, 2013 8:56 AM
> *To:* <openid-specs-ab at lists.openid.net>
> *Subject:* [Openid-specs-ab] proposed POST response type for OAuth/Connect
> ****
>
> ** **
>
> As discussed during today's call [1], attached is the pseudo-standard
> document I wrote up earlier this year describing an HTTP POST response type
> (effectively a POST binding) for OAuth/OIDC. ****
>
> I know everyone has a lot of docs to read right now but this one is *very*
> short and has a good example. ****
>
> We've found this approach to work well in practice and be easy to
> implement.****
>
> It can be done as a straight extension, as illustrated with this doc, or
> could incorporated into core connect.****
>
> ** **
>
> As John mentioned, the main drawback of this approach is proliferation of
> the Response Types registry. Which is kind of ugly but something that no
> one will care much about once it's done. It's also more of a consequence of
> the response type constructs put forth by OAuth than it is with this
> particular extension.****
>
> Thanks,
> Brian****
>
>
> [1]
> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20131014/004062.html
>
>
> ****
>
> ** **
>
>
>
> ****
>
> ** **
>



-- 
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131017/91703b56/attachment.html>


More information about the Openid-specs-ab mailing list