Comment 2 for bug 1208280

V3 auth is intended to be a pluggable framework to enable multi-factor and multi-roundtrip (i.e. challenge-response) authentications.

"methods" let the server know which (auth) methods the client is authenticating with. If server does not support a method on the list, it should failed with a 401 and body of the response must contain a list of methods the server supports. If methods is omitted in the request, server must response with a 400.

All methods in the request must be succeeded in order for the server to issue a token. Otherwise, server must return a 401 with additional information in the response if one or more methods in the request did not succeeded. For example, server may issue a challenge such as next token code in order to fulfill the authentication.

Keystone defines two standard methods, "password" and "token". I would expect additional methods to be started off in contrib, with detail documents on with the method payloads, for both initial request and addition challenge/response if any. If a cloud provider support additional methods that are not in Keystone rep, it is the cloud provider's responsibility to get them documented.

Keystone does not dictate how many or which methods the client must used to authenticate a given user. That's up to the cloud provider/deployer the client is interacting with. Keystone will authenticate whatever methods the client presented and let the client know the methods used to obtain the token in the token data response. It is up to the cloud provider/deployer to determine what that token can and cannot do. For example, a token that was obtained with a multi-factor method may have access to additional services then a token that was obtain with a password method.