[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Authentication
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/200307/msg00079.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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]