RE: [security-services] Credentials Collector proposal for SAML 2 .0...

Regarding Slava's comment #1 (the notion of hiding permanent credentials from a CC-translator), I think this is an important issue to consider. From a very practical point of view, one can divide Authentication Authorities to two general categories:

a. AA's that need to see the actual credential (i.e., an LDAP directory that does not expose the password hash and must "see" the password to authenticate the user), and

b. AA's that need not necessarily see the credential to authenticate the user (e.g., any kind of challenge response protocol, such as Kerberos) .

I believe it is difficult to fulfill credential-protection when the authentication authority is in category (a) above, at least with standard off-the-shelf products in this category.

Good comments. I agree that protection of certain authenticators is worth pointing out, even if we don't solve it in this first round. Also, the concept of an AA-Validator could be included as a fourth architecture (or as a twist on the existing ones). What do others think?

Carlisle,

I like the proposal - good start!

Few comments/suggestions:

1. One interesting topic worth considering for the Discussion or Issues/Requirements section - protection/blinding of certain types of authenticators from CC in the CC-Translator scenario. In other words - in some deployments, where CC-Translator and AA are in separate security domains, it is often undesirable to reveal certain types of authenticators (static shared secrets, e.g. passwords) to CC-Translator. Such protection may not be needed for one-time passwords and challenge-response methods. I am not sure how to accomplish that - it could either non-standard (Type 2 protocol?) or out-of-SAML-scope topic, but nevertheless, I think, it is worthwhile pointing out this issue..

2. Using WS-Trust lingo - AA can be viewed as a Security Token Service (STS) with an interesting scenario of AA/STS being WS-Trust Credential Validatior as it is described in WS-Trust spec. So, AA-Validator could possibly be another (fourth) deployment scenario where CC-Authenticator will invoke AA-Validator to validate certification path and/or cert revocation status, for example. Or this scenario could be hybridized with the CC-Authenticator scenario.

I also support your recommendation for Approach #3 - and RSA Security, as well as other co-authors of the spec strongly advocating submission of WS-Trust spec to standards organization.

Thank you,

Slava Kavsan

RSA Security

security-services message