Comment 4 for bug 1208639

> you have to limit the conversation to domain-scoped tokens that have no roles

I don't see why? Why can't I pass a domain-scoped token (a.k.a. unscoped token in my worldview) back and forth for multi-factor before trading it in for a project-scoped token if that's what I want?

> What's the "huge cost?"

If you add a new API (that must be used), every client binding must be changed. Every app that uses those bindings must be tested with the new client. Every deployed app must be updated. Every deployed cloud must be updated, otherwise they won't work with clients that require the new API. The ecosystem is damaged when people find it hard to use because "my Erlang binding can't authenticate against cloud X, but does work fine against cloud Y". Puppies die and babies cry.

The reality today, is that if I need a domain token for a particular Nova call (let's say), then I need to use a V3 Identity API client with a V3 Identity API server. It's not wise to assume that'll be the baseline for a few years yet, so nova won't require a domain token, it'll build in a V2 backdoor.

If, instead, we let V2 clients and servers be first-class citizens in the V3 world, then everyone is happy. Nova can require a domain token. Clients don't need to be rewritten just yet. Clouds need only be updated when they expose functionality that require V3 domain tokens (i.e. we must upgrade Nova & Keystone at the same time), but even then clients don't need to be rewritten. Clients _do_ need to be rewritten if/when they want to use V3 specific functionality e.g. logging in to a non-default domain.

This is why users have a default domain, right; so we don't force every client to learn about domains? If we do the same for unscoped = domain tokens, then V3 becomes compatible with V2. Puppies and babies rejoice.