I think it's a fair question as to why basic policy should have this one variable. Why not require any form of LoA to be an advanced policy.
>From an implementation perspective it would be a huge tax on applications to >require they support advanced polices. It would be reasonable to require they >support basic policy under this profile and to do that we need to make it a >lightweight as possible. However, a very frequent request is to require >something better than a simple password for authentication. What I don't want is to see a lot of use cases broken because policy wants something better than a password and the client only supports basic policy. Having the LoA in basic policy was my attempt to make sure that gap did not happen. If there is some other way to ensure we can support things better than passwords while not mandating LoA support in the policy I would welcome it as I do want basic to be a simple as possible. Trevor -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Leif Johansson Sent: Wednesday, October 26, 2011 12:37 AM To: [email protected] Subject: Re: [plasma] Levels of assurance -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/25/2011 08:56 PM, Fitch, Scott C wrote: > Is it necessary to require levels of assurance in the Basic Policy > requirements? I definitely think it's appropriate for Advanced Policies. But > I wonder whether including levels of assurance in Basic Policies will impede > adoption. > > Also, the fact that there are multiple LOA frameworks out there makes it > difficult to meet the requirement to NOT require a priori bilateral > agreements between the sender and recipient for Basic Policies. If the sender > and recipient use different LOA scales, then some type of prior agreement > must be in place to map the two scales. I don't think plasma wants to get > into the business of creating a standard LOA mapping for interoperability. > Supporting multiple LOA frameworks is partly a technical issue and partly a policy issue. The technical issue is that we need a way to communicate LOA per transaction. In SAML WebSSO there are technical controls (AuthenticationContext) for communicating LOA [1] [1] http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-assurance-profile.html Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6nuLYACgkQ8Jx8FtbMZnfPbQCeNkiKi0I/hoDUHz8d3ayq3ciy 7pkAnRtZwv6MNhBi19OnFwtNha4SjOmh =hkLH -----END PGP SIGNATURE----- _______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma _______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma
