[OpenID] Assertion Quality Extension => openid.importance

Manger, James H James.H.Manger at team.telstra.com
Wed Dec 13 00:42:08 UTC 2006


The RP is not saying “this is very very important to *me*”.  It is saying “in my opinion, this is likely to be very very important to *you*”.  Consequently, it is not a contradiction for the RP to also say “I leave it to you as to the specifics”.

> Does participating in OpenID mean the RP giving up this policy control?
Yes, fully participating in OpenID means the RP gives up some policy control.  An RP cannot simultaneously 1) accept its users choices of OPs, and 2) get trusted assertions as to the authentication quality.  The first implies accepting any OP.  The second implies accepting only the small subset of OPs trusted by the RP.

> How many such RPs will be willing to pay this price?
For most RPs there shouldn’t be a high price (if any price).  When the login only gives access to the user’s own resources (be they colour preferences, reputation, personal details, money…), then any inappropriately weak authentication of the user by their OP only affects that user.  The user pays a price, but not the RP.  This scenario covers a lot of services: Amazon (user’s book preferences, user’s payments); hotmail (user’s inbox); flickr (user’s photos)…
An RP may pay an indirect price.  The law may not accept that the user was in total control of the authentication mechanism so the user (not the RP) bears all responsibility.
A big scenario not covered is corporate access: the RP is a company, the user is an employee.  Login gives the user access to resources, but the RP still owns the resources.  Some control over the resources is delegated to the user, but not all.  Solutions: a) don’t use openid, b) trust your employees, c) use openid but only accept selected OPs.

> Fundamentally, I don't see how acknowledging that the RP may have certain expectations of the authentication event is somehow in conflict with user-centrism.
The hassle is that an RP expectation for, say, “hardotp” will prevent my spec-compliant OP software from logging me in even if I am using a triple-factor iris scan, 20-char password and smartcard to authenticate myself to my OP.
A related hassle is that when my OP supports a new authentication method (such as a strong password-authenticated key agreement scheme (eg SRP)), existing RPs will not recognize this method as strong enough for the RP’s expectations – regardless of the method’s actual strength.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20061213/0cae6586/attachment-0002.htm>


More information about the specs mailing list