+1. Let's get 2.0 deployed and figure out what it might be lacking before just starting on 3.0.
On Feb 3, 2008, at 11:05 PM, Johannes Ernst wrote: > Amen. Let's build (optional) extensions, and only if that absolutely > does not work for an essential feature, meekly suggest that the > smallest possible set of changes be made to an existing spec. > > Note that any term such as "OpenID 3.0" is mostly a marketing / > branding term, just like "OpenID 2.0". What it really means is what > underlying specs are being "packaged" into a larger term. > > On Feb 2, 2008, at 2:36, Martin Atkins wrote: > >> >> I apologise that this message doesn't directly address any of the >> points >> you've made, but others have been doing that. >> >> I just want to make a general point: >> In my opinion, we should resist the urge to start specing "OpenID >> 3.0" >> (aka OpenID vNext) and try to do everything else that needs to be >> done >> with extensions now. OpenID 2.0 has laid the framework for >> decentralized >> extensibility, so it should now be much easier to work within that >> framework. >> >> If it turns out that some particular feature absolutely can't be done >> without making a new Authentication spec release then so be it, but >> ideally I think we want 2.0 to be stable for many years to come to >> avoid >> repeating all of the current pain of incompatible versions and the >> poor >> user experience that creates. >> >> >> McGovern, James F (HTSC, IT) wrote: >>> Figured I would ask if anyone is interested in brainstorming the >>> next >>> version of OpenID and how it can be used in Enterprise B2B settings >>> and >>> not solely focusing on consumerish interactions. Some things that I >>> would like to see in the next version are: >>> >>> 1. A discussion on how AuthZ can converge with OpenID >>> 2. Modeling of relationships >>> 3. Not allowing an OpenID to be a vector for SQL Injection and >>> putting >>> something around what it should look like >>> 4. A way to indicate to the relying party what level of >>> authentication >>> has occurred such as did the OP check a password, how did it >>> validate a >>> user. Without this, there is no way that a trust model could be >>> established in a credible way. >>> >>> 5. A way for OpenID relying parties to filter out Ops. In a business >>> scenario, if I run the Sun employee store, I may only want the Sun >>> OP to >>> talk with me. >>> >> _______________________________________________ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
