I do not think that these pieces of middleware belong in the core swift repo.
1) Including them in swift would require swift to depend on keystone for full testing.
2) (When the middleware was created) Keystone's API was in a state of constant flux. Keystone has changed quite a bit since then, so this may not be the case anymore.
3) Swift does not require Keystone to run (and in fact many production environments don't use keystone at all). [1]
4) We have previously removed auth systems from swift's core code in order to simplify the codebase and allow separate dev cycles. All that is included now is the most basic auth system required for dev work, stand-alone tests, and POC deployments.
Our thought thus far has been that auth systems providing auth for swift have the responsibility to maintain their integration code. It's not swift's responsibility to manage and maintain code for every auth system that wants to provide an auth mechanism for swift.
That being said, there has been quite a bit of recent conversation about the concept of *-contrib areas for each project that include optional add-ons/extensions/plugins/etc or alternative APIs for each project. I expect these conversations to continue next week in person at the summit. One option is for the swift keystone middleware to be a part of such a contrib area.
It sounds like there are good reasons for both projects to not want to include these pieces of middleware in their respective core repos. Perhaps a contrib area can be a compromise, but that does not answer who is responsible for it (ie who maintains the code?). I think that's a separate, but related, question.
