Potential Future Projects
|
English | 日本語 | 中文(中国大陆) | +/- |
These are the beginnings of a list of potential projects we may or may not work on in the future.
API that causes relying parties to migrate from a user's old identifier to a new identifier
Suggested, in passing, by Dan Lyke on the mailing list http://openid.net/pipermail/user-experience/2006-October/000015.html
Reputation Brokers
From a Claimed Identifier, a Relying Party should be able to get a list of, for lack of a better phrase, "Reputation Brokers". if the Relying Party trusts one of those brokers, it can ask for a list of traits about the Claimed Identifier that the Reputation Broker will stand behind.
An example might be that the Identity Provider has taken some steps to verify that there's a human on the other end, to help keep comment spam bots under control.
REST/SOAP/HTTP Bindings
OpenID 2.0 bindings for REST/SOAP/HTTP APIs, now that HTTP redirect is deprecated in OpenID 2.0. As mentioned on the mailing list http://openid.net/pipermail/specs/2006-November/000861.html
Relying Party Best Practices
It would be worthwhile to define an agreed-apon set of Relying Party Best Practices against which RP sites can be evaluated and given some kind of score or certification. While we don't necessarily want to get into the formal certification boat, this is likely to be useful for RP implementors and OpenID directory services.
User-accompanied Data Exchange
User-accompanied Data Exchange allows two parties to exchange a user's private information with the permission and oversight of that user. OpenID Exchange 1.0 aims to provide a transport for this.
Decentralized Group Membership
Specification Refactoring
The Specification Refactoring Project is an attempt to refactor the main specifications for OpenID to reduce the amount of required reading for those new to OpenID and to add more articulation points where new specifications or new versions of existing specifications can be added later without altering the core specifications.
Updated DH and Hash Algorithms
Consider allowing Eliptic Curve Diffie-Hellman and SHA-384, as discussed in NIST SP 800-56, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography and FIPS 180-2, SHA-1, SHA-256, SHA-384, and SHA-512.
ZeroConf
There are issues with OpenID in ZeroConf deployments, in which OpenIDs are of the form http://computername.local/... as the computername may change depending by which computer on a network attempted to register computername first.
