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"

Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/jenkins/authentication/tokens/api/AuthenticationTokenContext.java
src/main/java/jenkins/authentication/tokens/api/AuthenticationTokenSource.java
src/main/java/jenkins/authentication/tokens/api/AuthenticationTokens.java
src/test/java/jenkins/authentication/tokens/api/AuthenticationTokenContextTest.java
http://jenkins-ci.org/commit/authentication-tokens-plugin/4e5848a765d2d19c2059aac8147a74dfd28ce80e
Log:
JENKINS-29370 Add the concept of an authentication token context

• Filtering token sources (as originally requested in JENKINS-29370) 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)

Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/jenkins/authentication/tokens/api/AuthenticationTokenContext.java
src/main/java/jenkins/authentication/tokens/api/AuthenticationTokenSource.java
src/main/java/jenkins/authentication/tokens/api/AuthenticationTokens.java
src/test/java/jenkins/authentication/tokens/api/AuthenticationTokenContextTest.java
http://jenkins-ci.org/commit/authentication-tokens-plugin/34165eef209c2af53feb1b25151b54e64b43cd57
Log:
Merge pull request #3 from jenkinsci/jenkins-29370-context

JENKINS-29370 Add the concept of an authentication token context

Compare: https://github.com/jenkinsci/authentication-tokens-plugin/compare/ac2edca70e1e...34165eef209c

Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/jenkins/authentication/tokens/api/AuthenticationTokens.java
src/test/java/jenkins/authentication/tokens/api/AuthenticationTokenContextTest.java
http://jenkins-ci.org/commit/authentication-tokens-plugin/2f8268d5a0eaf7844743de1e73d08816a7bc62d4
Log:
JENKINS-29370 Need the ability to convert the best match of a selection of credentials

The API in 1.2 was adjusted to address root use case requirement