[OpenID] Durability of authorized sessions

[Tony Locke]

Thanks for this Allen, I'd only grasped half the picture and forgotten
about the session with the OP.

Also, you suggest a scheme where an OP indicates whether an id is
suitable for high value transactions. What about taking this one step
further and have the OP give a monetary value that it'll refund if it
wrongly authenticates a user? Then if a transaction goes wrong and
it's the OP's fault, the RP can get a refund from the OP. If the end
user is affected, they would seek redress from the RP. This eliminates
buck-passing between the RP and OP.

If the end user provides an OpenId that doesn't have a high enough
refund value, the RP would be entitled to reject it.

What's in it for the OP? Well, they could charge the end user for
OpenIds that they issue with a refund guarantee. This would also have
the benefit of providing a badly needed income stream for the OP.

-Tony.

On 28/11/2007, Allen Tom <openid at allentom.com> wrote:
> Hi Tony,
>
> I was referring to the session that the user has with their OP.
> Hypothetically, consumer oriented OPs may issue long lived sessions that
> persist across browser restarts and IP address changes. Users of these OPs
> may login to OpenID RPs without having to reauthenticate with their OP. In
> scenarios like this, the OP may very well be aware that its OpenIDs are not
> sufficient to authorize high value transactions, in particular, the user may
> have been using a shared computer and forgot to logout, or the users
> credentials may have been stolen via an XSS or MITM attack.
>
> These security shortcomings can be addressed by using short lived sessions
> that do not persist across browser restarts, and also by tying the
> credentials to a particular IP address, however there's a usability cost in
> that users will need to frequently enter their password.
>
> Again, it would be very nice to have a standard mechanism for an OP to
> indicate that its OpenIDs are not suitable for high value transactions. If
> there is not a mechanism to do this, then OPs may need to blacklist these
> RPs on a case by case basis, which is certainly not a scalable or desirable
> solution. Alternatively, OPs may need to have a whilelist of acceptable RPs
> which is also contrary to the spirit of OpenID.
>
> Allen
>
>
> Tony Locke wrote:
> Allen Tom wrote:


> [...] authorizing financial transactions generally requires that
the
> credentials be relatively short lived (like an hour) and be tied to
a
> specific IP address. In contrast, consumer oriented websites generally
tend
> to issue long lived credentials that are not bound to an IP address
(as
> consumers tend to roam and get re-IPed fairly often). A
consumer-focused
> OpenID Provider may issue long lived credentials that
persist across browser
> sessions and IP address changes so that their
users don't need to type their
> password very often.

> As I understand it, with OpenId it's the RP and not the Provider
> that
decides how long the original authentication lasts, and it's also
> the
RP that decides what constitutes a session (ie, whether a session
> is
broken by a change of IP address). I guess most RPs define a session
with
> a cookie that persists until you close the browser. More
stringent RPs could
> demand re-authentication every 30 minutes, say,
and on each change of IP,
> and perhaps if 10 minutes goes by without
any
> interaction.

Regards,

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