Re: [dss] Authentication (fixed typo - bad URL)

["jmessing" <jmessing@law-on-line.com>]

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 <trevp@trevp.net>
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.
>
>