2009

deekayen started by suggesting that there aren't enough users of the OpenID module to justify it being in core. Boris Mann, RobLoach, and Dries shot that down and won't fixed the issue as a strategic decision.

catch and chx re-opened the issue. Heine agreeed with Dries on stategy, but saying that we need to work on Open ID 2.0.

2010

webchick pointed out that Heine and Christian made several improvements to OpenID in the 7.x release. Heine suggested that the module needs a rewrite because Open ID 1.1 and 2.0 are handled by the same functions. webchick tried to facilitate some progress on 8.x improvements with amc and taite11.

2011

deekayen proposed another removal patch to bump the thread. chx did +1. Damien Tournoud, sun, RobLoach, 1kenthomas, webchick and others did -1. sun introduced OAuth to the discussion, which gained traction through wojtha and Sylvain Lecoy setting tasks on external auth initiatives. chx later flipped and was ok with OpenID in core since wojtha took over maintainership. After getting some core commits, wojtha flipped and voted to remove OpenID from core. sun switched to "on the fence," but still had hope to stir an initiative. deekayen proposed another removal patch. moshe does a +1.

2013

ParisLiakos attempted to fix OpenID and suggested it's completely out of sync with the rest of core - rolls a new patch. Crell, cweagans, quicksketch, bojanz, walkah, c960657, chx, moshe all +1 so far. The issue gets sent back to Dries by Crell for a strategic discussion. Dries approved OpenID removal and patch #81 is waiting for the QA engine to get fixed. #70 passed QA before the d.o information leak caused infrastructure changes.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Boris Mann’s picture

"whereas in 6.x newbie admins could have just activated it without really knowing what it does" -- which is one of the reasons we put it in core in the first place.

If you made that argument, the same could probably be said of aggregator, taxonomy, and a host of other features like, oh, I don't know -- RSS -- *when they were first introduced*.

Anyway that wants OpenID would more likely just install D6 rather than stick on D5, so I don't think your stats hold water.

Other than stats, got any reasoned arguments why it should be removed? Other than smallcore :P

deekayen’s picture

"whereas in 6.x newbie admins could have just activated it without really knowing what it does" -- which is one of the reasons we put it in core in the first place.

To accomplish what? Get a bunch of people to say "Huh. Wonder what that is." Just because it's in core doesn't mean people will know what it does, why they should activate it, or that their users will use it.

I'm trying to be real about this - using actual usage stats. Declaring that users who want OpenID will skip to D6 seems to be based on a guess and I don't think that makes anymore sense than saying people who want Mollom will use D6 rather than stick on D5. That would be like saying OpenID and Mollom are somehow better in D6 to cause people to want to upgrade.

I can't just ignore stats in this and fall back on my guesses of what people are thinking.

So I take it your argument is that while only 2.8% of 5.x sites use OpenID, that somehow by having included it in OpenID, there is a high, and significant percentage of sites that use it in D6. I counter your argument with statistics from the top 10 modules on the usage page. I hope we can agree that the top modules are the most likely to make it into core. I feel silly even comparing the paltry 566 sites to the thousands of installations of these others.

Rank Project 5.x % installed 6.x % installed
10 Date 42 23
9 ImageCache 32 25
8 Image API 21 28
7 FileField 10 31
6 Image Field 50 26
5 Admin Menu 41 31
4 Pathauto 63 37
3 Token 74 48
2 CCK 73 52
1 Views 83 58

These are projects where in some cases have been added to D7 core, yet their usage went down for D6. I read this to mean that as the pool of alternate technologies increases, it dilutes the percentage sites that each project gets deployed on. Drupal has a huge pool of authentication methods for Shibboleth, SMTP, LDAP, OAuth, Mediawiki, IMAP, PAM, Facebook, CRAM, Google Apps, certificate based, Windows Live, SlAuth, XMPP?, and probably others I haven't seen yet.

At least the SMTP library had 960 installations for 5.x compared to the 566 of OpenID module. Everyone has an email account, right? Even if they don't have SMTP on their free Yahoo mail, they should have some sort of SMTP login with their ISP, so why not include that? Facebook has 250 million active users, so why not include it's authentication module? Even if people don't know what OpenID is, they should have heard of Facebook and have an account with those kinds of numbers.

I thought Domenic's analogy was right on "OpenID is the Betamax of accessible SSO, and FBConnect/MySpaceID are VHS. This isn't about technology, it's about adoption." Nobody wants to login to drupal.org using their MySpace OpenID just like nobody wants to login to check their Gmail using their Yahoo OpenID. It's just weird. Moreover, all the time savings you're supposed to get by skipping the new account registration is circumvented by most sites after you get redirected to your vidoop picture screen to login, then make a username and password on the site to store your OpenID in, then verify your OpenID profile information and set your sex.

I'm not saying to plant a bomb on OpenID and blow it away, just move it to contrib. There we can see if people demand it, it can actually earn its place in core rather than just be crammed in as a model of new, essential technology. Fortunately we have a large pool of admins here that run large sites and can vouch for whether OpenID is used on them and can run queries to see how many accounts have stored an OpenID login. I can volunteer the free information that I have 0.00% usage of OpenID on all the sites I run. The older business audiences I cater to have no interest in OpenIDs. They just want to save their login to autofill from Internet Exploder and move on about their business.

Does the project module store OpenID usage in 6.x and it's just not exposing it? That would be helpful for this whole discussion.

Dries’s picture

Status: Needs review » Closed (won't fix)

Sorry, OpenID is staying in Drupal 7. It has long-term strategic value. We can revisit this for Drupal 8.

catch’s picture

Status: Closed (won't fix) » Needs review

We only get usage for core, not for optional core modules in project usage stats, so that's unlikely to happen. Nothing will happen here unless there's someone willing to maintain OpenID in contrib, I don't use it either though.

catch’s picture

Status: Needs review » Closed (won't fix)

Cross posted. Adding Drupal 8 tag in the absence of a version.

joshmiller’s picture

Status: Closed (won't fix) » Postponed

So, it is essentially "postponed" and needs to be discussed for Drupal 8. Though, it is not "postponed for a good reason" more like "postponed until we get another year under our belts and should revisit this..."

jennifer.chang’s picture

subscribe

amc’s picture

Issue tags: +OpenID

Gee, didn't we win a contest for being one of the first to include OpenID in the first place?

Heine’s picture

Sorry, OpenID is staying in Drupal 7. It has long-term strategic value. We can revisit this for Drupal 8.

I agree that OpenID has long-term strategic value. We do need to work a bit on it. I have severe doubts that we have an Open ID 2.0 compliant RP implementation. See also http://drupal.org/project/issues/drupal?text=&status=Open&priorities=All...

Let's not make this the next BlogAPI.

RobLoach’s picture

I vote a negative on the removal of OpenID. I do vote a positive on improving it, however.

deekayen’s picture

Status: Postponed » Closed (won't fix)

I don't need to be entertained. Let's just make it official.

alexanderpas’s picture

Version: 7.x-dev » 8.x-dev
Issue tags: -OpenID

Do NOT use tags for duplicating the "Assigned" or "Component" fields.

mcurry’s picture

subscribe

chx’s picture

Status: Closed (won't fix) » Active

This is definitely an active issue because we sorely lack OpenID maintainers. Let's revisit this in D8.

webchick’s picture

Hm? Christian Schmidt and Heine Deelstra made several great improvements to OpenID during the 7.x release.

Heine’s picture

I'm not sure how Christian thinks about this, but for D8 we need a lot more test and likely a large rewrite of the module. Atm, it is pretty difficult to change code without breaking something because multiple specs (1.1 and 2.0) are handled by the same functions.

OneTwoTait’s picture

As one of the vast majority of users - non-technical, impatient and unsure if I want to register on any given website - I will say that I don't know what OpenID is! Well, I didn't before I read a few threads and the OpenID website...problem is, hardly anybody else is going to go to such lengths.

As a website owner and marketer, I know that even making viewers work a few extra seconds can be a deadly mistake for a website, asking them to spend a few minutes to figure out OpenID would be a bad mistake. As the module interface is now, I feel that enabling the OpenID module would be a waste of space on a webpage. The exception would be websites in particular niches for which there are over a couple percent of users that actually know what it is.

If it was presented as "Login with [google logo][yahoo logo][wordpress logo]". That would be another story! That could be a very useful tool that would actually increase logins/registrations.

webchick’s picture

Yeah, I definitely support making the OpenID module interface more friendly. I agree that it is way, way too hard to understand in its current incarnation.

taite11: Would you be willing to start another issue, cross-referenced here and marked for 8.x (7.x is feature-frozen) where you toss around some ideas, maybe as annotated screenshots, about what we could do differently to help?

Taxoman’s picture

OpenID works great for me, really simplifying having lots of logins to several Drupal sites I administer and participate in, especially being able to set a strong password that later can be left unused, and use OpenID instead. (important to in fact set that password to a strong one before forgetting about that login method, for security reasons...).

For a site admin using install profiles or other means of "site templates" to deploy many sites and limit unnecessary extra work, it is very useful to have accounts included with a strong password set and open-id ready to use on the new sites.

When it comes to user adoption, this is a long term strategic effort, which I really hope also Drupal can help carry furher. We need both to improve and simplify and to document and advocate its use.

I would in fact like to have a way of requiring people to use OpenID to get access to a particular site (turn off the username and password fields in the login dialog), and also to be able to enforce (limit) a list of approved openid providers for use with a particular site. (filing this as a feature request in a separate issue)

That - along with good information to the users, could help spread its adoption.

As Rob said in #10: negative on removing, positive on improving.

deekayen’s picture

Status: Active » Needs review
FileSize
119.91 KB

I still don't think openid needs to be a core feature. Here's a patch to talk about and get tested...

chx’s picture

http://www.quora.com/What-s-wrong-with-OpenID excellent discussion on the topic. Some gems "OpenID adds complexity to solve a complex problem." 'OpenID is the worst possible "solution" I have ever seen in my entire life to a problem that most people don't really have. ' / 'It is a product in search of a problem. The "pain" it addresses is negligible. ' etc

Damien Tournoud’s picture

You have my -1 here.

webchick’s picture

I'm fine replacing OpenID with a similar open standards-based SSO solution. As far as I know though, none exists. So therefore I back Dries on this being strategically important for Drupal as an open initiative for our project to support (and yes, in core).

deekayen’s picture

If it's so great, then d.o should be using it and greggles et al keep putting effort into custom stuff. I think this is an obvious thing to remove, so I'm having trouble making a well-formed argument.

webchick’s picture

I don't think I argued that it was "so great"; the quora thread alludes to some of the UX challenges among other things. I argued that there is no viable alternative that's based on open standards.

It's worth reading the background issue at #353425: Allow other sites to use drupal.org user identities for login (in D7 infrastructure, without shared secrets) for context as to why we're using Bakery and not OpenID. The Cliff's notes version is:

  • Open ID is just the "login/authentication" portion of the open stack. If you want to do other things like share profile information, layer metadata on top of relationships, etc. (which we do on drupal.org going forward) you need other tools.
  • A lot of those other tools were of sub-standard quality in contrib and were going to require quite a bit of work to get them in shape.
  • Additionally, our existing sub-sites (groups.drupal.org, association.drupal.org, etc.) had existing user records on them, the migration issues with combining these records over at id.drupal.org were going to be very non-trivial.
  • And so, at the end of the day, we're a do-ocracy. Key members of the infrastructure team "did" a solution—Bakery module—that was far less code and required far less effort than fixing up all the various requisite dependencies. A working SSO solution for drupal.org was a blocker to the redesign, and practicality won the day over ideology. It happens.

However, just because OpenID (arguably) wasn't the right solution for drupal.org, doesn't mean it's not the right solution for lots of other people out there. Especially now in 2011, when all wordpress.com, livejournal.com, yahoo.com, etc. IDs are OpenIDs.

Further, the open identity movement is a huge attraction for highly technical people who believe in free software movement. We want those people using Drupal and contributing to Drupal. It's a huge thing for our project that we are listed at http://openid.net/developers/ as an example implementation.

On a more practical level, having a SSO solution like OpenID in core tests our framework's ability to support multiple authentication mechanisms. The extensive tests for OpenID module help us ferret out breakages with that when we do refactoring in user.module or Form API.

And finally, if we relegate OpenID to contrib, we are giving it the same importance as something like Facebook Connect and I take serious issue with that on an ideological/philosophical level as an open source developer, and on a privacy concern level as well. Since the average user is finally starting to get half a clue about the complete and utter disregard for their privacy that services like Facebook have, it's more important than ever that the open source world offer viable alternatives. Especially projects like Drupal, since we've been a major driver of widespread adoption of open standards in the past (e.g. RSS way back in the day, and more recently RDFa).

Now's not the time to drop OpenID module from core. Now's the time to make our OpenID support the most easy-to-use and secure out there.

RobLoach’s picture

Status: Needs review » Needs work

Instead of implementing our own OpenID library, it would probably help a lot if we adopted one of the existing OpenID PHP Libraries. Would reduce a huge work load from the Drupal core OpenID module. I'm still a huge -1 on its removal and a big +1 on improving it. Implementing and maintaining the whole thing ourselves is crazy talk. Let's work with others in the OpenID world so that the load on us isn't as big.

As for usability, OpenID Selector is a pretty common plugin for improving the login workflow (example). There's also a pretty good breakdown of other OpenID login solutions out there.

Setting to Needs Work, as webchick stated we don't want to remove OpenID.

webchick’s picture

Yeah, that I definitely don't have a problem with. We've long left behind the age where we didn't incorporate 3rd party libraries (most of /misc/*.js is exactly that).

However, based on conversations from last year on the one of the mailing lists, my general impression was that there isn't a 3rd party PHP library out there that's really great (or maybe it was in reference specifically to any GPL library; can't recall the details). James Walker had talked about maybe starting an initiative between status.net, Drupal, WordPress, and some other projects to combine forces on an awesome GPL OpenID library that they all could use. This wasn't appropriate to pursue for core during D7 code freeze, but would totally be appropriate now for D8 (and D7 contrib).

I'll see if I can raise him to chime in here with more thoughts.

webchick’s picture

Btw, let's start breaking these "make OpenID suck less" things up into sub-issues rather than combining them here under an issue about removing OpenID.

Maybe also worth a Community Initiatives page under http://drupal.org/community-initiatives/drupal-core?

RobLoach’s picture

Good tag name ;-).

chx’s picture

If you want to be the white knight of openid then let's add a *server* to core. But first, we should have more than two people caring one of whom is also busy as the security team leader...

1kenthomas’s picture

// subscribing
drop--;
improve++;

wojtha’s picture

I'm have been working for some time on integration of one openid provider which doesn't work in Drupal 7 and in Drupal 6 it basically works but in a not secure way. I started around 5 patches, some of them are really needed in all current versions of Drupal from 6.x to 8.x. I touched even the drupal_http_request() with one or two issues. The current state of openid is really "sucky" (and somehow insecure under certain conditions) in all current versions of Drupal :-/

As chx and webchick have said I feel like the openid initiave is a must.

decalant’s picture

Subscribe (and hopefully not make ass of self by unintentionally including "make OpenID suck less" issue tag...)

sun’s picture

To stay cutting-edge and on top of the game, we not only need to improve our OpenID client implementation and add an OpenID server, but also add OAuth or SAML implementations. All of these are fairly complex open standards, which won't succeed in contrib.

The Drupal project has a unique opportunity to lead the Internet to what has been coined as Web 3.0 some years ago: a semantic, transparent web of services and identities.

I'm not sure whether the Drupal community has any experts in this field, but now would be the perfect time to raise your hand. I'd be more than happy to discuss and review patches (but I'm no expert).

wojtha’s picture

@sun openid initiave => external identities initiative

Tasks/priorities:
1. make OpenID client suck less
2. integrate OAuth
3. integrate SAML
4. integrate OpenID server

Yes it will be nice, I feel like OpenID is loosing continuosly, OAuth will actually have more implementation than OpenID that time IMO. But I will prefer OAuth client in core instead of OpenID server, "server" functionality is more advanced usage of identity services and it will take different set of problems to the core.

But without initiative and without some responsible people and some QA I will rather remove these services from core completely and provide API for external auth services only after my personal experience that we are not able to fix openid errors in core in the timeframe of months even if some of them represents security threats...

Sylvain Lecoy’s picture

I started writing a minimal OAuth client module here: http://drupal.org/sandbox/SylvainLecoy/1127118

It rely on the PECL OAuth C Extension but I plan to make it compatible with Zend and a default PHP Lib for shared hosting.

I introduced an interface DrupalOAuthAdapter that let implementers choosing their library of choice. I also implemented helpers methods for dealing more generally with external identities. You can have a look, the base code is small enough to understand easily.

Sylvain Lecoy’s picture

This is also related to #817118: Remove {authmap} and migrate OpenID entries to their own table.

I also created a task to integrate OAuth in Core as I fully support this here: #1148990: Add an oauth identity provider to core

chx’s picture

Status: Needs work » Closed (won't fix)

With http://drupal.org/commitlog/commit/2/c15dc6cbeeafa6b86db33d2dc15d57a6a3a... I feel much better about the future of OpenID in core.

giorgio79’s picture

#27 We already have OpenID Selector in contrib
http://drupal.org/project/openid_selector

My only problem with it, as with the default OpenID module is that it only shows up on the login page, but not the registration page. In my understanding, the whole point of OpenID is not having to enter details again to register, but just click on a provider on the REGISTRATION page, which is not how Drupal uses it. (others who noted this: http://drupal.org/node/257194)

Anyway, this is for a different issue :) If you agree though, I will raise it as an issue.

Raisded it here: #1172340: OpenID: Implement OpenID on User Registration page as well

niccolox’s picture

have created a discussion in the OpenID group - OmniAuth OpenID Single Signon - OpenID Single Signon Lives (SOrta)
http://groups.drupal.org/node/154879

the out-dated but sophisticated OSSO (OpenID Simple (Not Single) Sign On) solution on github from Development Seed has been reworked and there are now two modules in sandbox and two install profiles thanks to http://drupal.org/user/359937 xamanu who is working on an installation profile called OmniAuth OpenID Single Signon

the Central American Drupal meetup just happened and there is a presentation in Spanish about this
http://drupal-centroamerica.org/en/sesion/proveedor-de-openid-con-drupal
http://drupal-centroamerica.org/sites/default/files/proveedor-openid.odp

I've asked for paid support, but also looking to work with others on a peer-to-peer basis, looking for helpers here to work through this with me

I've personally reach a blocker with my project based on site-networks because of single-signon or even simple signon

the sandboxed modules
http://drupal.org/sandbox/xamanu/1153576
http://drupal.org/sandbox/xamanu/1153574

drush make http://gitorious.org/openid_sso/makefiles/blobs/raw/master/osso_provider_ax.make
drush make http://gitorious.org/openid_sso/makefiles/blobs/raw/master/osso_relying_ax.make
bojanz’s picture

Status: Closed (won't fix) » Active

Do we want to re-examine this in light of recent talks (#1255674: [meta] Make core maintainable)?
chx closed the issue in #39 because wojtha took over as maintainer. Wojtha now says in the issue linked above:

I agree even with the removal of the Openid despite I'm its core maintainer... but the core committing process is driving me nuts. I spent more than 100 hours in the Openid issue queue during last several months mostly with my 4 major/critical patches which all are on the edge of the security issues. Just one was commited during these 7 months of effort (!!!) to get all these fixes in... Especially Drupal 7 OpenID implementation is broken for all providers, it works only "by accident", using completely wrong or stripped identifiers, which are still in most cases unique, but not safe in the longer time interval...

deekayen’s picture

#42 makes it sound like the opposite of #35 is true, that in fact having the module in core is keeping the module from being successful. If the OpenID module was moved to an environment with more development freedom that someone other than the core committers could become the ultimate expert on accepting and releasing fixes to the module.

catch’s picture

I think the main reason wojtha's patches aren't getting committed is because there are at most 2-3 people qualified to review them (Christian and Heine, walkah if he was still around).

No one else that I know of feels remotely qualified in terms of the spec, the best we can do is look at tests and see if it looks good.

I have done a little bit with OpenID and OpenID Provider for day job (tracking down 16 second login times), and it did not make me want to do more or get familiar with the spec, just made me realise how esoteric it all is.

That's a good case for having it as a contrib module with a couple of co-maintainers. If people want to keep it in core, then something needs to happen to get those patches in quicker, which seems impossible at the moment without a relaxation of peer review criteria, or people just RTBCing the patches on trust (which I will do if this issue stays open more than a week without a firm resolution - nudge me if I don't).

deekayen’s picture

Two people is enough to get me to refresh my patch. Will start on that now.

sun’s picture

I'm still on the fence with this. The points in #35 and #36 still stand. Instead of removing it, we should try to assemble a proper initiative for these technologies. As mentioned on the meta-issue, I think this is crucial for the long-term success and adoption of Drupal.

I personally started to look into OAuth recently, and could very well imagine to put some muscles behind that for core later on. OpenID is a different beast, which I'm personally not familiar with yet. In general, however, I think it should be possible to find more experienced people and maintainers for this in our community.

deekayen’s picture

Status: Active » Needs review
FileSize
123.95 KB

Let's see how this works out...

Complete removal of OpenID afaik.

Status: Needs review » Needs work

The last submitted patch, remove_openid_from_core-556380-47.patch, failed testing.

deekayen’s picture

Status: Needs work » Needs review
FileSize
125.76 KB

Image-related patches apparently need additional diff parameters:

git diff --binary --full-index

catch’s picture

To put #44 a different way, here's the problem with OpenID:

http://drupal.org/project/issues/search/drupal?status%5B%5D=8&component%...

When you only have one or two people writing all those patches, they are going to get stuck at that status.

So the patches need to get to RTBC and committed to core fast, or wojtha should have commit access to an OpenID contrib project. Note that two of the patches currently make up 25% of the critical issues against Drupal 7 and 8.

catch’s picture

I just RTBCed the two criticals, with an explanation, let's see if that moves things along.

niccolox’s picture

this is a positive development

I think what needs to happen with Open ID is that it needs to be bundled like Domain Access or Deploy

so that it becomes a more unified module set, rather than the current scattering of various OpenID related modules

there is actually now an a production ready OpenID Relying and OpenID Single Sign On Relying module for D6 and D7

these should be all bundled into OpenID so that you actually get a package of the complete functionality, no more bs matching versions etc

http://drupal.org/project/openid_sso_relying

see xamanu's work, based on earlier Development Seed OpenID
http://drupal.org/user/359937

OpenID Client AX
OpenID Single Sign On Relying Party
OpenID Single Sign On Provider
OpenID Profile
OpenID Content Profile Field
OpenID Provider AX
OpenID Attribute Exchange API

there are also two excellent OpenID based installation profiles

Omniauth by xamanu http://gitorious.org/omniauth
Openprofiles by louis https://github.com/lelizondo

the Openprofiles installation profile is interesting because its starting to integrate the Oauth angle

niccolox’s picture

related to #52 have tested the various OpenID Single Signon Relying modules for D6 and D7 and they work well

little bit fiddly, and documentation needed, but it works for D6 and D7

see my comments
http://drupal.org/node/1218198#comment-4918182

imho OpenID should become contrib for D6 AND D7 AND D8

xamanu’s picture

I'm not sure if it'd be a good or bad idea to exclude OpenID from core. Equally I can see benefits from both. Yes, the periphery modules (AX and SSO stuff) could get some more direct influence into the basic OpenID module but it can be done right now as well. But this would be not more than just two or three patches that haven't even been written yet because periphery modules of OpenID have to improve a lot before these patches have a real base for the need of these changes. IMHO it is not about if OpenID is in core or not, it is about that OpenID could need more attention and active work.

I would love to see D8 going more into the "smallcore" direction than including f.e. WYSIWYG editors in core. So OpenID could be excluded, which makes sense considering the small percentage of use. But why exclude a module that has a "long-term strategic value" and consist only of few lines when talking about making Drupal an all rounder beast?!

deekayen’s picture

I think leaving OpenID (and poll, blog, profile, others) in core is a symptom of a difficult process for contrib installation. One thing Drupal does leverage better than any other is a single, central authority for downloading contributed modules and Drupal doesn't use that to its advantage as I think it could.

As I said over at #233301-123: Remove blog module from core, I think what core ought to be working at is a core interface that links to contrib better. Rather than downloading a tgz or zip, uploading files, going to modules page and activating, or using a 1985 terminal interface with drush, I think core ought to be able to browse contrib from within an installed Drupal profile and install modules without ancillary download processes, chmodding, or ftping.

Fix that interaction with contrib, and I don't think we'll need to keep things like OpenID in core because each Drupal installation would be able to reach out and grab it either during install or after. I have no idea how to bridge this gap, btw.

niccolox’s picture

why not use the App system promoted by Phase II Technology for OpenPublic, its basically exactly what you describe but using Kit compliant features.. all we need do is make it more atomized i.e. for modules

moshe weitzman’s picture

Status: Needs review » Needs work
Issue tags: +External Identities Initiative

The last submitted patch, remove_openid_from_core-556380-49.patch, failed testing.

moshe weitzman’s picture

Needs a reroll. +1 from me, for all the reasons already mentioned.

deekayen’s picture

Here's a re-roll.

sun’s picture

Still -1 from me, for all reasons already mentioned.

Actually, this issue was preemptively re-opened based on discussions in #1255674: [meta] Make core maintainable - but, the actual conclusion of that discussion was to #1273344: Establish heuristics for core feature evaluation and to base decisions like this on more rational and more reasonable data.

I'd recommend to mark this issue postponed.

Meanwhile I'm executing @catch's proposal in #44.

deekayen’s picture

Status: Needs work » Needs review

Naturally, I didn't change the status for the re-roll to mean anything...

Taxoman’s picture

These are important arguments aside from the technical discussion:
I think that this should be more of a strategic discussion than a technical one when it comes to keeping it in core or not.

- webchick in #26: "And finally, if we relegate OpenID to contrib, we are giving it the same importance as something like Facebook Connect and I take serious issue with that on an ideological/philosophical level as an open source developer, and on a privacy concern level as well. Since the average user is finally starting to get half a clue about the complete and utter disregard for their privacy that services like Facebook have, it's more important than ever that the open source world offer viable alternatives. Especially projects like Drupal, since we've been a major driver of widespread adoption of open standards in the past"

- sun in #35: "The Drupal project has a unique opportunity to lead the Internet to what has been coined as Web 3.0 some years ago: a semantic, transparent web of services and identities."

Robin Millette’s picture

-1 on this issue.

While I'm not 100% up to date on OpenID, last I heard, the next version will build upon oAuth's next version. I would really like to see/keep these in core. I think there's still hope for open standards.

Next, I'm going to want PuSH, webfinger, salmon and activitystreams, but that's another matter ;-)

sun’s picture

The only people I've seen working on OpenID module in the recent past are @c952734629492 and @wojtha.

Again, I had the impression they had troubles finding anyone to review their patches. Even though a few of them are major/critical issues.

Can we get another update from the main people working on OpenID on the current status of the module and maintenance?

Damien Tournoud’s picture

I'm still -1. We probably want to switch to an OpenID library, but I still believe OpenID should be in core. So should OAuth, if we could find a client library that doesn't suck (and is ported to OAuth 2.0).

Sylvain Lecoy’s picture

Jooblay.net’s picture

Thanks to all you drupal hard-cores:) I am in support of slow moving cognitive functional (Agile) development:) It seems a lot of times the community may move a little to fast to hook_that and hook_this:) take that out, patch that!

Even looking over the issue queue on a daily basis I run across so many issues that really are not issues at all but lack of patients:(

I am in for openID to be dropped in D8 but agree it is functional and needs a maintainer. I would be willing to help support and co-maintain, though I am a slow sloth-y coder:)

Totally agree with web chick and sun on open source is the future... Great comment web chick on face book the commercial spying company! Lets just call it what it really is... It is not so much an issue of privacy but what governments do with your information? I think Julian can attest to the glass ceiling...

Thanks again to Sun, Damien Tournoud, Web chick and everyone else powering the drupal community:)

Heine’s picture

ParisLiakos’s picture

coming here from #1623114: Remove drupal_exit()

My first step, was to go and try to fix openid: #2004812: Introduce Drupal 8 to openid module
But in process i realized this module is completely out of sync with rest of the core and its API for a while..
nice example: http://api.drupal.org/api/drupal/core%21modules%21openid%21openid.inc/fu...

so i think noone really cares for this module..imo just move this to contrib...or please rewrite the module and add some docs on...most functions of openid.inc has absolutely no docs, it is so hard for me to gasp whats going on

Crell’s picture

If we have no capacity to modernize it, we should euthanize it. At this point OpenID has more or less lost as a protocol, which is sad but is what it is.

cweagans’s picture

Here's the part of the above patch that's not git rm -rf core/modules/openid

cweagans’s picture

And FWIW, I'm very much in favor of this change.

quicksketch’s picture

I'm in support of removing OpenID also.

As far as I understand our situation, OpenID 2.0 was approved over 6 years ago. In those 6 years, we have yet to actually implement the 2.0 version of the spec. I could be wrong here, but AFAIK, we're basically still running the same module as it was written back in Drupal 5 against the original spec.

Other services that utilize some kind of attribute/profile exchange are significantly more useful and popular with both site builders and users. Facebook, Twitter, G+, Flickr, and others all use OAuth for authentication and provide mechanisms for attribute exchange. Meanwhile the OpenID Attribute Exchange and OpenID Client Attribute Exchange modules have 50 sites total using them for D6 and no released D7 version at all. Because few OpenID providers implement attribute exchange through their OpenID login, the usefulness of supporting OpenID at all is limited.

There are better solutions than OpenID that are better supported. Including OpenID in core is like a big red flag saying, "Look how old I am!" Let's remove it and redouble contrib efforts on OAuth, which has proved you can have a widely-used authentication module in contrib.

cweagans’s picture

IMO, this is something that should get Dries' opinion again. Last time he commented here was in 2009, so maybe time for a fresh look?

bojanz’s picture

+1 for removal.

OpenID Connect (the latest version of the standard) is built on top of OAuth 2.0, I've been digging into how feasible it would be to implement it in http://drupal.org/project/oauth2_server or in a module that depends on oauth2_server.

Jooblay.net’s picture

3rd party authentication is a really deep issue. Everyone wants to be the gate-keepers but really in the end no one wants to trust anyone with the keys. This is value added to a long history of security issues in general on the web for trusting others with information. Instead of taking the gate keeping stance we often opt for a cluster approach such as CAS and a strong password manager. At the core of authentication seems to be trust in the "idea" of allowing access to your account.

On one side you have the future of TIA (total information awareness) and on the other privacy hawks. In the end it seems as long as paranoia exists and people do not educate themselves you will end up pushing smaller clusters of authentication where the site owner has the keys and is the gate keeper.

Is open id used? Is it needed? Most developers I know really enjoy being the gate keepers...

walkah’s picture

Since this is in some respects my fault, I've been asked for my $0.02 CAD:

I am +1 in favour of removing the openid module from Drupal core for D8. Yes, this would mark the second time that a module of mine has been removed from core, and I believe I deserve a trophy of some sort for that distinction.

The reality is, however, that the OpenID 2.0 spec that we've tried to support is a bit of a dead man walking - as mentioned above, the new direction in that community is toward the OAuth2.0 based "OpenID Connect" ... while there is far more energy "in the wild" around pre-registered OAuth -based sign in flows (not to mention SAML and other more pure single sign-on methods). The reality is OpenID has/did not emerge as the 'one true solution' in this space. The solutions are still evolving and linking this to core's release cycle doesn't make sense (imnsho).

Strategically, I don't know that OpenID per se is the right thing to support. Rather, I think Drupal should maintain / re-establish a strong position amongst identity services (Mozilla Persona, etc deserve honourable mention here). Formal support for auth providers, mapping identifiers, etc would be wonderful things to support. Make it as easy as possible for contrib modules to exist for all the identity standards (consumer *and* provider) - until the rest of the internet realizes this is important and there is an emergent standard (if there ever is one).

Crell’s picture

Assigned: Unassigned » Dries
Status: Needs review » Reviewed & tested by the community

Assigning back to Dries to either commit or argue for why we shouldn't.

deekayen’s picture

I created an issue summary for Dries as part of my re-affirming my initial post and patches to remove this.

deekayen’s picture

This changes all the same stuff as #70, but adds CHANGELOG.txt (removal from core note) and MAINTAINERS.txt (removing the entry for OpenID). They're both at the top of the patch.

Status: Reviewed & tested by the community » Needs work
Issue tags: -External Identities Initiative

The last submitted patch, drupal-remove_openid_from_core-556380-81.patch, failed testing.

ParisLiakos’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
Issue tags: +External Identities Initiative

The last submitted patch, drupal-remove_openid_from_core-556380-81.patch, failed testing.

c960657’s picture

I agree with the previous comments.

I have much sympathy for OpenID, and I really hoped that it would take off. But so far is has not become the one solution to rule them all, and the future of this field is very uncertain, so even if the module was well-maintained, I think it has lost it's relevance as a core module. In my opinion, no standard currently has so wide-spread support that we should support it in core.

If you take a look into the code in the OpenID module, it's pretty clear that Drupal makes it very difficult to create an authentication module that integrates nicely with the existing login forms, the account creation flow etc. I think the core efforts should be spent on making it easy for contrib modules to work as authentication providers (and allow disabling the built-in authentication mechanism). Support for different login frameworks can be developed in contrib based open standards (OpenID), priorietary systems (Facebook) or enterprise single sign-on systems (Drupal.org bakery). Site-owners should be able to install one or more authentication modules that matches the target audience of the web site.

deekayen’s picture

Status: Needs work » Needs review
Issue tags: -External Identities Initiative
deekayen’s picture

Issue summary: View changes

Generated a new issue summary

Status: Needs review » Needs work

The last submitted patch, drupal-remove_openid_from_core-556380-81.patch, failed testing.

ParisLiakos’s picture

Status: Needs work » Needs review
Issue tags: +External Identities Initiative
Dries’s picture

Assigned: Dries » Unassigned

I'm ok with removing this from core.

chx’s picture

Let's do this -- but let's review how login works. I thought we split that in D7 into phases and should be easier to replace but if not, definitely let's fix it in another issue.

moshe weitzman’s picture

I'm pretty familiar with the login code. Removing OpenID has no bearing on anything. Other modules are welcome to add #validate handlers to the login form and they should set #authenticated = TRUE in $form_state if they can verify the creds. Then the form is valid and submit handlers fire as usual.

In other words, there is no blocker here that I can see.

moshe weitzman’s picture

Issue summary: View changes

Updated issue summary.

deekayen’s picture

Issue summary: View changes

Updated issue summary to include Dries update.

RobLoach’s picture

Issue tags: +Platform Initiative

Tagging

Sylvain Lecoy’s picture

Moshe, while #authenticated = TRUE can be a good option, we have to think at cases where authentication is completely delegated to an external system, for instance https://drupal.org/project/siteminder (which is used by some major companies when speaking about drupal as intranet).

The login pipeline is completely delegated, e.g. no login form is created from drupal. On a system under siteminder protection, the website assumes through a HTTP header added by the agent protection the web server that a user is logged in or not. Thus, in this case, we have no possibilities to hook the login and the only option we have is to rely on the HTTP header, which will load the current user through an "authmap".

ParisLiakos’s picture

moshe weitzman’s picture

Sylvain - yes, thats a common use case as well. We've had that since 2003 - https://drupal.org/project/webserver_auth.

Status: Needs review » Needs work

The last submitted patch, drupal-remove_openid_from_core-556380-81.patch, failed testing.

Jooblay.net’s picture

It would seem to make further sense to investigate the possibility of Drupal becoming an authority in 3rd party auth. Who better then to hold the keys then a wild crew of coders?

ParisLiakos’s picture

Status: Needs work » Needs review

#1798654: Clean faulty HTML in help description of field widgets should be responsible for the last failed runs..retrying now that reverted

#81: drupal-remove_openid_from_core-556380-81.patch queued for re-testing.

ParisLiakos’s picture

Status: Needs review » Reviewed & tested by the community

finally

catch’s picture

Is anyone prepared to put the existing core code back into the contrib project for this either before/after it's removed from core?

cweagans’s picture

I'd be happy to create a project and move the code there after it's removed from core, but I've learned my lesson with BlogAPI. I will not maintain it, but I'd be happy to fork out commit access and/or node ownership to whoever wants it.

deekayen’s picture

There's already a project. See #2010442-1: Transfer OpenID back to contrib for the patch I submitted to get the contrib part started.

anarcat’s picture

@cweagans - what lesson did you learn from BlogAPI? Maybe you can followup in #2010442: Transfer OpenID back to contrib?

cweagans’s picture

Lesson: don't take over maintainership of core to contrib modules =P

Dries’s picture

Committed to 8.x. Thanks for volunteering cweagans.

Marking 'needs work' until cweagans' project is properly setup. :)

Dries’s picture

Status: Reviewed & tested by the community » Needs work

Committed to 8.x. Thanks for volunteering cweagans.

Marking 'needs work' until cweagans' project is properly setup. :)

cweagans’s picture

Sent a note to walkah (since he owns http://drupal.org/project/openid):

Hey there,

Are you interested in continuing to maintain OpenID in contrib? If so, I was wondering if you could commit this: https://drupal.org/node/2010442

If not, can you make a note here: http://drupal.org/node/556380 with permission to assign node ownership so that somebody can commit it and maintain it?

Thanks!

jibran’s picture

Title: Remove OpenID from core » Change notice: Remove OpenID from core
Priority: Normal » Critical
Status: Needs work » Active
Issue tags: +Needs change record

it definitely needs change notification.

ParisLiakos’s picture

Title: Change notice: Remove OpenID from core » Remove OpenID from core
Priority: Critical » Normal
Status: Active » Needs work
Issue tags: -Needs change record

https://drupal.org/node/2013074

back to needs work till its transferred to contrib

Pancho’s picture

Issue tags: +revisit before beta

tagging

walkah’s picture

I've added cweagans as a maintainer for the openid contrib module.

cweagans’s picture

cweagans’s picture

Status: Needs work » Fixed

We should establish an easy to follow process for moving modules from core to contrib with git filter-branch or git subtree, cause for people that don't do this particular operation very often, it can be very confusing. I figured it out, though, so I guess we can close this.

http://drupalcode.org/project/openid.git/tree/refs/heads/8.x-1.x

Removing tag. There's nothing left to do here.

Status: Fixed » Closed (fixed)
Issue tags: -revisit before beta, -External Identities Initiative, -Platform Initiative

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Updated issue summary to add chx and moshe to +1.

catch’s picture

Issue tags: -revisit before beta

This could be added back to core at any point after release in a minor version if we actually wanted to, untagging.