So what Identifier types are you thinking of? http:/https: URL acct: email looking identifiers XRI other?
I was thinking that ".onion" TLD's could be routed through Tor, though perhaps it would be better to let XRI gateway to it. The goal for OpenID v.Next is having a number (perhaps 1, but probably more) of specifications that lay out how discovery will take place: as soon as there are enough to cover all the critical areas, v.Next should be counted done on that point. The key question, to my mind, is whether more plugins can be accepted (and officially approved) before v.Next+1 - if not, establishing some criteria in advance (and as the WG members who are approving/denying the v.Next specs are still familiar with the criteria they use for that process) could be a helpful addition to the charter.
Do you think some should be MTI (Mandatory to Implement) and others optional?
I'm not concerned about various features being mandatory to develop for v.Next, or include in the libraries, so long as developers are free to selectively disable the methods *they* distrust and still call it OpenID.
The strongest I'd be comfortable with is "enabled by default" (feel free to warn me that disabling it can break OpenID), but if I *want* to shoot myself in the foot, let me.
-Shade _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
