OAuth WRAP as next-gen OpenID? (WAS: Problem with nonces and HTTP GET)

Andrew Arnott andrewarnott at gmail.com
Thu Jan 28 14:29:46 UTC 2010


Forking thread...

Hmm.... so my disclaimer here is that I haven't read Nat's spec on artifact
binding, so perhaps what I'm suggesting is almost the same thing as you've
already got...

Allen had mentioned that artifact binding requires sharing state potentially
across data centers, which is difficult.  And some have mentioned on this
and/or the general list (I forgot which) that Twitter's OAuth authentication
is sort of next-gen OpenID (which I've never understood).  But I wonder...
if we're going with the artifact approach anyway, would using OAuth WRAP
make sense here?  Consider...

The RP/consumer sends the user to the IdP/OP/SP to authorize an OAuth WRAP
token, and the OP sends the user back to the RP with a small message.  The
RP then requests the authorized token (I forgot the exact terminology here
in the WRAP spec) from the IdP, and uses that token to request
authentication status for the authorizing user, along with any attributes
the RP needs.  So it's out of band, can result in a large response, or
whatever.

So far, I've not added any value to OpenID+artifact binding.

Except that between the authorizing of the token and when the RP finally
asks for attributes, the IdP hasn't had to store any artifact or state of
the user, since the WRAP token is self-signed by the token issuer and
contains the information the RP is allowed to request.

The OAuth WRAP token MAY still be valid.  Even if for a very short time, it
would allow the RP to "replay" this token, possibly solving the problem of
the RP's return_to page being re-fetched (although probably not by itself
since the RP would still have to know not to re-authorize the token).  But
it would also allow the RP to auto-log-off the user if the IdP began
reporting that the user was logged off.

Just a thought.  But it does seem that OpenID+artifact is a substantial
change from 2.0, so it's interesting to consider equally large change
alternatives that are already adopted just in case they make sense.  There's
obviously a lot here that I haven't discussed or even considered, so feel
free to trash the idea. :)

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre


On Thu, Jan 28, 2010 at 3:02 AM, Nat Sakimura <n-sakimura at nri.co.jp> wrote:

>  (2010/01/28 16:21), Allen Tom wrote:
>
> Hi all -
>
> Before I get started – I agree that in an ideal world, we’d have full end
> to end SSL, old browsers would be banned, and we’d POST data.
>
> However, requiring RPs to support SSL isn’t going to help adoption and is
> deal breaker for most applications that want to use OpenID today.
> Encouraging RPs to use SSL is a great idea – but it should not be required.
>
> Although most browsers can support URLs > 2KB, some proxy servers choke on
> URLs > 2KB. This is not fun to debug.
>
> I add one more thing here: Many mobile browsers choke.
>
>
> In practice, enforcing the nonce only gives the illusion of additional
> security. If there’s a MITM, instead of replaying (or pre-playing) the
> assertion, the attacker will just steal the browser cookies instead.
> Assertions should have a limited lifetime – but this can be enforced by
> checking the timestamp and allowing for a narrow replay window.
>
> POST is technically the ideal solution, but results in a degraded UX. The
> proprietary market leaders have set the bar very high and we need to offer
> an open alternative that is just as good, if not better. We really aren’t
> going to get anywhere with a clunky UX.  POST adds additional latency, and
> can cause strange warnings and a blank interstitial (the self submitting
> form).
>
> I really would like to be able to return an assertion using AX with a lot
> of attributes, and Hybrid that can fit within the 2KB limit. This is needed
> just to reach parity with the proprietary stuff.
>
> Artifact Binding :-) Our implementation is returning (for the experiment
> purpose) assertion that is well over 5MB with AX.
>
> =nat
>
>
> Allen
>
>
> _______________________________________________
> specs mailing listspecs at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs
>
>
>
> --
> Nat Sakimura (n-sakimura at nri.co.jp)
> Nomura Research Institute, Ltd.
> Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100128/9f26d4cd/attachment.htm>


More information about the specs mailing list