On Thu, Apr 25, 2013 at 11:31 AM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Thu, 25 Apr 2013 09:11:00 -0400
seth vidal <skvidal(a)fedoraproject.org> wrote:
> Well I think the idea is simple enough - if there is one, branded and
> obvious login page - and that page is openid then we're not training
> our users to type their passwords into random websites.
Right. I think this is definitely where we are headed, but we aren't
there yet. ;(
So, yes, I think we need to add support to fedocal and blockerbugs for
openid, but not sure it's a blocker for them moving to production now.
-1 blocker. We've discussed this numerous times. We can't keep changing
our mind about it; it's not fair to the application developers. They
follow the existing guidance about not typing your fedora password into a
non-Fedora site so they're in compliance with the current best practices.
People who can't stand to type their password into them also shouldn't be
typing their password into the wiki, pkgdb, bodhi, and etc -- so really,
they can't be Fedora contributors if they're drawing the line this strictly.
Moving forward, we might consider making it a blocker, especially
we have other things moved over to openid already, but I don't want to
change the goal posts for existing apps in the middle of the process.
Yeah, with emphasis on the once other things have moved over, I could
probably agree with this. There are some bumpy spots though -- for
instance, what happens when an app doesn't have openid support. We also
need to be aware that this can be an invasive request. If an application
needs to have authz (groups or permissions) then we may not be able to get
away with simple openid authn in the application and may need to code our
own thing to handle that. We also need to have a certain number of other
deployments done to feel confident that openid-for-our-own-apps isn't going
to hit any unexpected difficulties. Lack or certain information from fas,
inability of openid to scale, insecurities, etc.