Authentication (fixed typo - bad URL)

[Trevor Perrin <trevp@trevp.net>]

The issue of how our protocol relates to client-authentication methods has 
come up.  In particular:
  a) should these methods be relegated to the bindings, and not part of the 
protocol per se?
*or*
  b) should the protocol have some provision for sending 
tokens/assertions/etc. of some sort, and authenticating within the protocol 
itself.

The requirements doc only says:
"""
  3.10: Each binding may define authentication means (passwords, client 
certificates, etc.)
"""

Which implies (a).  However, the doc was substantially rewritten for 
version 8.  Before then, the text was more ambiguous:
"""
1.1.1      Authentication

1) None (or by other means, such as TLS/SSL, IPsec)
2) Directly to the server within the protocol (e.g. WS-Security)
3) Indirectly via an Authentication Authority (e.g. SAML)
4) Combinations of above
The protocol should be capable of supporting the above approaches to mutual 
authentication.  Bindings will fill in the details and mandate specific 
techniques.  The details of authentication techniques used to access a DSS 
server are not within the scope of this specification and there is no 
attempt by this specification to restrict such methods of authentication.
"""

This text was taken pretty directly from a post by Robert:
http://lists.oasis-open.org/archives/dss/200301/msg00032.html

Anyways, I think the important point is (2) - does this mean (a) or 
(b)?  To me, it seems that WS-Security just another lower-layer "binding", 
so this leans toward (a).  But then why isn't (2) collapsed in (1)?


I like (a) cause authentication usually isn't a matter of just sending a 
"token", usually you have to cryptographically sign something, or do some 
challenge-response, or whatever.  So I think we should rely on lower-level 
protocols to transfer these tokens and handle any cryptography/protocol 
aspects.

We may need to "profile" these bindings - i.e., we may need to make a 
WS-Security profile that says what types of tokens are allowed, and how 
they should be used to sign the message.

But I don't think we need to add anything to the core protocol to account 
for these, I think we can do the work later of figuring out how to utilize 
these lower layers.


Trevor