In my view filtering token sources in the consumer of this API is against the spirit of the API.
The consumer should not be required to know which token sources are valid and which are not valid. If it knew which token sources were valid it would just use them directly.
The point of this API is to enable the consumer to specify the context within which they want to use the token and then have the credentials (of a type unknown to the consumer) be converted (by a converter of a type unknown to the consumer) into a token (of a type known to the consumer)
So the root use case here is something like this:
1. As a consumer I am going to authenticate a XYZHttpConnection using Digest authentication, please give me a matcher for credentials that can be used in this context... now please convert this specific credential into the XYZHttpAuthenticator instance
In the 1.1 version of the authentication tokens API we assume that there would be separate classes for a BasicXYZHttpAuthenticator and a DigestXYZHttpAuthenticator, but that is an arrogant assumption to make. We should not be assuming anything of the library we are mapping to. In other words, in the context of this example the library should be free to have on and only one XYZHttpAuthenticator class that perhaps gas a getScheme() method to differentiate between basic and digest authentication.
So the real solution for this issue is to allow a more fine grained specification of the context within which we will use the token. Thus instead of saying "we want a XYZHttpAuthenticator token", we should be saying "we want a XYZHttpAuthenticator token for the purpose of digest authentication"