[OpenID] Durability of authorized sessions

[Peter Williams]

yes. I accept that analogy.
 
I had understood checkid_immediate as addressing several parallel ajax-controls on a RP's landing page, rendered after one has been through an RPs login experience (which may be an openid process and results in an OP-local-cookie). Each individual client-side control on the landing page would only render if the site could complete checkid_immediate using the SAME OP as that used in the RP's login expererience. Being async, some might render, some might not - depending on the result of the webSSO.
 
This doesn't seem to cater for the mashup case, where each of _several_ RP sites autonomously controlling several client control on some single page decides on its own PAPE policy and its own choice of OP. Then the problems comes down to...WHO is in control over that poor user's pageset flow experience when one of the 4 control-RPs imposes its rules on (a) PAPE minimums (b) when to insist on an interaction with the user (that the other controls have no interest in ensuring).
 
 
 
 
 
 

________________________________

From: general-bounces at openid.net on behalf of Martin Atkins
Sent: Wed 11/28/2007 10:38 AM
To: general at openid.net
Subject: Re: [OpenID] Durability of authorized sessions



Peter Williams wrote:
> 
> 
> In SAML2, an RP such as RP2 can provide a second (PAPE-like) field requiring that the OP should NOT involve the user interactively - in formulating its claimset. That is... it is really saying: use an OP-local-cookie issued earlier, where reasonable. If its not reasonable to still rely on such a cookie, the OP should respond with - unable to satisfy RP requirements: no claims available. The RP can then invoke the flow again, lessening the "no-interruption" restriction and thereby allowing the OP to present an interactive logon experience...featuring password, or bio, or 2-factor or whatever X grade of user auth satisfes the RP2's PAPE requirement. If RP1 comes back again to the OP, with a PAPE requirement that is higher than X, then the OP MUST interupt the pageflow and satisfy the requirement at the higher standard (assuming it supports it).
> 

As far as a non-interactive handshake goes, OpenID already supports such
a thing. Jyte is an example of a site which uses it: if you return to
Jyte and have a cookie which says you are http://joe.example.com/, it'll
attempt a non-interactive handshake with your OP and attempt to
automatically log you in. If this fails[1], you need to click the login
link as normal.

(Or something like that, at least. It's been a while since I looked into
it.)

This is indicated by setting the openid.mode value to
"checkid_immediate". The OP can optionally return a URL to send the user
to in order to authorize the transaction, but I don't think that this is
used much in practice.

-----------------------


[1] Failure could be due to the "no session cookie" case or it could be
due to the OP requiring the user to approve the RP before proceeding.




_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general