OpenIDForLargeProviders
From IIW
Contents
OpenID for Large Providers
presented by shreyas
"large" is vague... but focusing on large deployments
what does openid identifier look like?
1. revealing contact info via openid url (i.e. aol)
- concerns about contextual spam
- concerns about revealing contact info and leading to abuse
- reports of fraud and abuse
2. attribute exchange
- this is a fairly sensitive topic considering liability... and exchanging information
- liability with sending data to relying parties... it's a legitimate issue as 1 person per day comes and tries to sue the iDP
- could we have a user-focused audit-queue of all RP access to data?
- do all RPs need to go through a ToS process? whitelisting RPs?
- maybe look to email with SPF and stuff...
- public keys for RPs?
- thinking about how the social graph could be leveraged to figure out someone being good/bad... looking at friend's list
- should openid provider pre-register?
Have a look at Trusted_Data_Exchange. It discusses about these issues and proposes a solution. Among the proposals are the contract strucure, RP public keys etc. It is written as OpenID extention but can be used for other protocols like SAML/Liberty. (=nat)
3. liability | fraud | account deletion | forgot password
- how to determine RPs with which you have agreements and not...
- will there be SLAs between iDPs and RPs?
- we should also remember that iDPs will have value in playing a central role... therefore if they are liable, that might be worth it to them if they can act like credit card companies and make money off of assuming that liability
Have a look at Trusted_Data_Exchange. It discusses about issue #1 and proposes a solution. The liability issue: we could constract the contract to be between the end user and RP, in which case, OPs probably is not liable. Of course, if an OP is prepared to assume more responsibility, they could, with more liability and perhaps fees. But I have to comment that #3 is more like a job of Reputation Service than OP, actually. (=nat)
4.recycling identifiers
- 100s of thousands of accounts are deleted by big providers every day... how do we handle fall back mechanisms?
- how do we differentiate accounts that could be highly valuable? i.e. someone is using their OpenID for high value transactions but also for abuse...
- RPs should have fallback procedures (i.e. receiving emails) -- need best practices... see: basecamp, use fallback email, temp u/p
- fits well into the InfoCard space in terms of having multiple types of identity
- again, high value in being an iDP -- maybe there will be paid-for iDPs which are more lenient or will be more generous before deleting your account for abuse...
- what about domain name expiration? is NetSol liable in that case?
5.authentication policies
- problem with persistent logins (being logged in for 14 days, etc)
- many large sites allow people to login and stay logged in indefinitely...
- what is strength/quality of assertions being made? should a password be required to provide assertions? credentials can be sniffed in the clear if stored in cookies, etc
- is openid only good for low value transactions?
- universal signout?
- pape extension? be able to assert that "this assertion should not be trusted for high value transactions"
- like credit cards... "accepts visa, mastercard, american express but not diners"... so people would need to have a "high value transaction iDP" to do those kinds of transactions
Misc Notes
in terms of privacy, vidoop info about you is always opt-in made public but controlled via robot.txt...
AOL tried to make sure that if people do crawling of accounts gives same response for real accounts and fake records; openid 2.0 allows for directed identity, so AOL will be adopting that...
an issue of "moving communities"... using identifiers for that purpose...
readable ID but not contactable...
poll -- pretty URL vs hashed URL...
Macduff thinks directed identity is the way to go.
not a lot of good best practices on how/when to identity OpenID identifier for relying parties...
