Just having a pass through EDR1 and here are some comments so far.
* Section 2.1 *
The callers proof of identity is being described as a token or
credential, I think it may be more accurate to somehow include response
to a challenge in there. As an example with HTTP Digest, the response
is not a credential and I think describing it as a token is pushing the
meaning of token.
* HttpAuthenticationMechanism *
I have raised this previously but I still think by including both
request validation and challenge generation in a single method there is
a missing option to support multiple authentication mechanisms
concurrently - a common example I see is CLIENT_CERT with SPNEGO with
one or more form of username /password authentication.
Outside of this we have needed to solve a number of additional issues
related to HTTP authentication such as unsolicited authentication,
caching of an authentication result without undermining the mechanism,
having the authenticated available when unsecured resources subsequently
accessed.
* Identity Store *
We have been working through some similar issues with the WildFly
Elytron project we are currently integrating into WildFly. So that we
can support many different authentication mechanisms we have reached the
point where our equivalent of an identity store can be used to both
obtain a credential representation that a mechanism can use to verify
the response that it has received and an alternative approach where a
mechanism can pass in evidence for verification.
Looking at the current proposed API for IdentityStore I am not so sure
it is a credential being verified, rather it is verifying either a
response to a challenge or a token.
That first comment may be more about relating the API to terminology but
the big risk with this is that the implementation details from the
authentication mechanism now start to leak into the identity store
implementation. So in addition to being able to interact with the store
of identities the store now needs to be aware of the requirements of
different mechanisms if it was to be re-usable.
Related to this, as an application server vendor - to provide a default
implementation of this interface I would assume a default set of
supported credential types would need to be listed somewhere?
I will have another pass through the APIs but these are some of the main
points that jumped out so far related to issues that we have needed to
work through ourselves.
Regards,
Darran Lofthouse.