[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] NIST prohibits use of SAML assertions at LOA 4
All I support Martin's suggestion. Our organization prefers a standard approach. We want to avoid exceptions for LOA 4, if we can. Please add this topic to the SSTC Bi-Weekly Quorum Con-Call meeting agenda. Best regards David David Staggs, JD, CISSP (SAIC) Veterans Health Administration Chief Health Informatics Office Emerging Health Technologies -----Original Message----- From: Smith, Martin [mailto:Martin.Smith@DHS.GOV] Sent: Sunday, June 29, 2008 5:49 PM To: Paul Madsen; Cahill, Conor P Cc: cantor.2@osu.edu; Eric Tiffany; Staggs, David (SAIC); OASIS SSTC Subject: RE: [security-services] NIST prohibits use of SAML assertions at LOA 4 So, would the TC be willing to provide a comment along the lines of this thread to NIST? I believe that would be considered carefully, and those of us in Fed agencies could endorse it. I believe it's important for Fed agencies to simplify the use of flexible and robust access-control facilities that use common authZ and authN data -- and eliminate the need for apps to implement a separate technology to leverage HSPD-12 credentials. Thanks, Martin Martin F. Smith Branch Chief, National Security Systems DHS/I&A/IM 202 447-3743 desk 202 441-9731 cell 888 272-3610 pager ________________________________ From: security-services-return-1423-martin.smith=dhs.gov@lists.oasis-open.org on behalf of Paul Madsen Sent: Fri 6/27/2008 7:48 PM To: Cahill, Conor P Cc: cantor.2@osu.edu; Eric Tiffany; Staggs, David (SAIC); OASIS SSTC Subject: Re: [security-services] NIST prohibits use of SAML assertions at LOA 4 more generally, rather than pick on SAML, the policy should preclude 'browser redirect SSO systems that rely on bearer tokens' paul Cahill, Conor P wrote: >> Well, it's interpreted in light of the fact that browsers cannot >> > perform > >> proof operations with SAML assertions. What they want is not PKI in >> general, but PKI between the relying party and the client. More than a >> bearer token, in other words. There's plenty to be said for that >> > argument. > > Yeah, but then they should be saying that they don't allow the browser > SSO > profile rather than disallowing the assertions. > > Conor > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > -- Paul Madsen e:paulmadsen @ ntt-at.com NTT p:613-482-0432 m:613-282-8647 aim:PaulMdsn5 web:connectid.blogspot.com --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]