Actually, we have created artifact binding implementation based on the
draft that I showed you guys at IIW. We now have ones for Java, Python,
PHP, and we are doing Ruby now. Java extended openid4java, and Python
and PHP extended JanRain. The same will be true for Ruby.
They work nicely, and we are going to be doing experiments with
Japanese mobile telcos in February.
As to the timing for specing, I am going to be submitting WG proposal
soon. I have the first draft to go with it, and I do not foresee too
much open issues with them, so it should not take too long to bake the
spec, hopefully. It actually is a very small spec, so it might finish
sooner than AX 1.1.
For those of you who are interested in Artifact Binding, please start
processing your Contribution Agreement, so that we can start the real
work without delay.
Nat Sakimura (=nat)
(2010/01/28 8:01), Allen Tom wrote:
At least with regards to HuffPo – we ended up
removing attributes from the request to get under the 2KB url limit,
which eliminated the security warning since we can return the response
via GET instead of POST.
At least in the near term, I’d like to compact AX so that we can
squeeze in more data – we should be able to do this for AX 1.1. OPs can
also implement this internal artifact mechanism to switch from HTTPS to
HTTP before returning the data.
In the longer term, some form of Artifact Binding would probably be
better, but I guess this would take longer to implement.
Allen
On 1/22/10 10:59 AM, "Brian Kissel" <[email protected]> wrote:
+1 Allen, here’s what I
get on HuffPo, not very compelling and probably a trigger to “Cancel”
to most users. We need to fix this ASAP!
Cheers,
Brian
___________
Brian Kissel <http://www.linkedin.com/pub/0/10/254>
CEO - JanRain, Inc.
[email protected]
Mobile: 503.342.2668 | Fax: 503.296.5502
519 SW 3rd Ave. Suite 600 Portland, OR 97204
Increase registrations, engage users, and grow your brand
with RPX. Learn more at www.rpxnow.com
<http://www.rpxnow.com/>
From:
[email protected]
[mailto:[email protected]]
On Behalf Of Allen Tom
Sent: Friday, January 22, 2010 10:43 AM
To: Andrew Arnott; John Bradley; Breno de Medeiros; specs
Subject: Re: Problem with nonces and HTTP GET
The SSL security warning is a really terrible
UX, and I agree that it doesn’t make sense to warn on POST but not on
GET.
Yahoo is running into the 2KB limit (and the associated SSL warning)
with alarming frequency and it’s really hurting OpenID relative to the
proprietary SSO solutions.
For a real live example of how the giant AX names are hurting OpenID,
see http://www.huffingtonpost.com
– click on the Login link, then the “Connect with Yahoo” button. This
kicks off the Hybrid OpenID+Oauth+AX flow which requires a POST
response – forcing the user to click through a security warning to
complete the sign in flow. The non-OpenID SSO choices
(Facebook/Twitter/GFC) do not have this issue.
With regards to changing browsers to not display SSL warnings for POST,
or relying on smart OpenID clients – we really need a solution right
now, since the proprietary alternatives are rapidly being adopted.
WRT the nonce – I think it would make more sense for RPs to just check
the timestamp, and allow replay for a “narrow” window, like 10 minutes.
There are many legitimate reasons why a request could be replayed –
intermediate proxy servers might do weird things, the user might hit
reload/back/forward etc.
Allen
On 1/22/10 10:06 AM, "Andrew Arnott" <[email protected]> wrote:
Ideally we could use POST, but avoid the browser warning that
information is crossing the SSL world into the non-SSL world. This
might be arguable anyway since sending information can be done with GET
or POST, so why warn for POST and not for GET? If we can get browsers
to not warn for POST we're gold.
Alternatively, and perhaps more likely, if we're moving in the
direction of smart client browser (plugins), and these have been shown
to benefit from extensions to the OpenID spec, perhaps we can leverage
these to always use POST without displaying the warning to the user
somehow.
--
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 Fri, Jan 22, 2010 at 9:14 AM, John Bradley <[email protected]>
wrote:
The big problem with POST is RP's that use non-ssl endpoints.
One possibility is that the IdP could look at the return_to and
discover if it is safe to use POST.
In SAML SSO POST is the most common way to return the token.
The other option is artifact binding. That way the nonce is not in the
GET, though you probably wind up with the same effect if the RP tries
to resolve the artifact more than once.
John B.
On 2010-01-22, at 12:39 PM, Andrew Arnott wrote:
HTTP GET is supposed to be completely effect-free on the server. But
nonces in OpenID messages violate that aspect of the HTTP spec, since
any subsequent GET with the same positive assertion will (or should)
fail. I speculate that some random login failures on StackOverflow <http://meta.stackoverflow.com/questions/32247/cant-login-to-so-with-openid-the-signature-verification-failed/36583#36583>
may be caused because a browser, an accelerator plugin, or a proxy
attempted to repeat the assertion-carrying GET request (since that's
supposed to be safe), and a subsequent request is the one whose
response is displayed in the browser, failing user login.
<http://meta.stackoverflow.com/questions/32247/cant-login-to-so-with-openid-the-signature-verification-failed/36583#36583>
POST is a better fit with the HTTP spec for how the message is actually
processed on the server. I know lately we've been looking for ways to
cram more data into < 2KB payloads so we can get off POST and onto
GET since the user experience is better. But I wonder if we can put
our heads together and figure out how to have our cake and eat it too
with this nonce problem. This error doesn't come up often, but it can
come up, apparently does come up, and is a natural side-effect of the
way OpenID communicates.
Any ideas?
--
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
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
|
