I did not have any specific APIs in mind when it comes to auth
modes
in general - there may be something more in JAAS, but i'm not
extremely familiar with it...

JAAS is the server side thing. At the client side, what can be
handy, is
to introduce a property (as Bill suggested), something like

"client.authenticator" which will map to ClientAuhenticator
interface,
and JAX-RS will offer few well-known imlpementations, I would
limit it
to BasicClientAuhenticator for a start. and the runtime would do:

I really do not want to define a security SPI. IMO, we don't need
one as
filters/interceptors can pretty much implement anything. I just
want a
simple portable way to connect to and interact with Java EE servlet
containers, i.e. support for HTTPS, Basic, Digest, Client-cert, and
Form
based authentication. I prefer a simple property-based approach, but
would support a more type-safe interface as long as it didn't
impose an
implementation constraints.

Either approach is fine for me, I do not mind.

Now, as far as Form is concerned, how interoperable is that, and what
exactly a client can do about if it is cookie based (this is what I
know
about it)?

The servlet spec defines the form parameters the login.html form must
have. It also defines the name of the cookie if that is the tracking
mechanism.

Actually, the point about SPI, it does not have to be SPI, just
simple
optional registration from the code only. Whatever the client
chooses,
it all ends up in HTTP Authorization, as far as the authentication is
concerned

I just didn't like your example of defining an authorization header
method. I think many of us delegate to Apache Client 4 for auth.

Sure, let the individual implementations decide how the authentication
is managed, I just don't want the fact that some stacks may prefer to
delegate to some embedded HTTP one affect the overall approach.

That's my point. With properties, or config objects, you don't care how
it is implemented.

I guess the question is, if we were to go the untyped way, how to group
the properties correctly, given that every authentication scheme has
its
own requirements/rules. Should we go half-way and offer a support for
Basic/Digest or offer a mechanism to get Spnego supported, etc.

AFAIK, Apache HTTP client offers a superior support for NTLM, but most
other mechanisms can be managed without it, as I said, ultimately it is
about populating Authorization header.

Client-cert does not involve authorization headers.

Agreed, it is at a lower level though, so support for populating
Authorization headers is orthogonal

Its not orthogonal, its irrelevant. If you want to write your own
protocol, then write a filter that sets the appropriate authorization
headers. Its pretty much how we support things like Openstack's Keystone
protocol.

What we're talking about here is providing built-in support for the HTTP
authentication mechanisms defined and supported in Java EE: Basic,
Digest, Form, client-cert. And also HTTPS.

I'd still question 'Form' - I think the 'responsibility' of the spec is
to ensure that the solutions known to work in the Java universe only are
not promoted if there's no evidence that 'Form' is supported well by
windows servers for example, after the client written in JAX-RS 2.0 does
not know how the server is implemented. But if it is known to be
supported across the server stacks, then +1