[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] X509 authn based attribute protocol profile
All, I am planning to discuss Conor's comments with my customer that is using the profile early next week, to see what we can do with them. Have a good weekend. V/R, ~ Rick -----Original Message----- From: Scott Cantor [mailto:cantor.2@osu.edu] Sent: Thursday, June 02, 2005 8:07 PM To: 'Conor P. Cahill'; 'SAML' Subject: RE: [security-services] X509 authn based attribute protocol profile > * There doesn't appear to be any tying of the DN > presented by the SP to an actual authentication event at the SP (e.g. > the SP can remember the DN for days, weeks, years > and reuse it whenever it wants). In fact, the SP could > just make up a DN and try it to see if it works or the SP could have > gotten the DN from another SP. Either we should solve this problem or > we should say that this has nothing to do with authentication and just > say it is DN based attribute lookup (we don't care how the DN got to > the SP as far as I can tell in the protocols). I made roughly the same argument originally, but couched it more in terms of restricting the profile to address only the attribute exchange and not the authentication process. The response, IIRC, was that without defining the specific use case (TLS client authn via HTTP), the overall use case wouldn't be implemented by products claiming to support the profile with any consistency and the customer wouldn't get their RFP shortcut. I agree with your position, but I don't think it's an easily solved problem to tie them together. Maybe the only compromise is to simply note the constraint that while the use case modeled may extend beyond the attribute query, the security mechanisms and trust models involved don't. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]