I fully agree on this.
It is required not only from AJAX scenario, but also from Assurance
Level discussions.
For example, in SP800-63rev.1, Level 1 assertion must expire in 12
hours, Level 3 assertion in 30 min,
and in IDABC Authentication Policy,
Level 1: 24 hours,
Level 2: 12 hours
Level 3: 2 hours
Level 4: Immediate (whatever it means...)
Regards,
=nat
Andrew Arnott wrote:
With the recent OpenID AJAX work I've been doing (blog commenting
<http://samples.dotnetopenauth.net/v3.2/openidrelyingpartywebforms/ajaxlogin.aspx>
and popup login <http://openidux.dotnetopenauth.net/>) I've run across
a problem that while small now, may grow as OpenID popularity
increases and AJAX use becomes more mainstream.
When an OP sends a positive assertion signed with a private
association, the RP currently has no idea how long this assertion is
valid. The OP has their own policy regarding how long before it
expires the assertion based on the response_nonce' timestamp. Some OPs
may reason "well, it should only take a few seconds for an RP to get
back to us to verify this, so any nonce more than 30 seconds old is
expired" in order to keep the used nonce bin from filling up too fast.
Here's the problem: at least with my own AJAX designs, the positive
assertion the user agent obtains from the OP is /not/ forwarded
immediately to the RP. Several assertions are gathered, and the user
picks which one to log into the RP with, and to help protect the
user's privacy, it's not ideal to send all assertions to the RP or
else it's easy for the RP to tie several identities together without
the user's consent./ / If the login screen is left open for several
minutes, these assertions can get stale. Particularly in the blog
commenting scenario where the user my acquire the positive assertion
before writing his blog comment and thereby could wait 15 minutes or
more before posting his comment.
So far, I'm mitigating this at the RP by choosing a "reasonable"
maximum lifetime for the assertion and the javascript automatically
renews the positive assertion after the assertion is assumed to have
expired. But since this guess at the assertion's lifetime is not
correct for an arbitrary OP, it would be great if with the positive
assertion signed with a private association the OP could indicate with
another parameter how long the assertion is valid for so the RP
javascript code can renew at the optimal interval.
What do you think?
--
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
