To me the only question is if by relying solely upon lower layers, it may still be possible to inadvertently create a real-life situation that is not covered either by the protocol or the lower layers. If we are reasonably sure that circumstance cannot occur, then I agree with you. By way of a hypothetical, what happens when a client establishes a direct connection with the server without passing through a gateway or being authenticated by a third party? How will the authentication be treated?
---------- Original Message ----------------------------------
From: Trevor Perrin <>
Date: Mon, 20 Oct 2003 14:02:09 -0700
>
>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
>
>
>
>
>
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php.
>
>
