Re: [plasma] Levels of assurance
Trevor Freeman <trevorf@exchange.microsoft.com> Wed, 26 October 2011 22:03 UTC
Return-Path: <trevorf@exchange.microsoft.com>
X-Original-To: plasma@ietfa.amsl.com
Delivered-To: plasma@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906EE21F8B6D for <plasma@ietfa.amsl.com>; Wed, 26 Oct 2011 15:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.099
X-Spam-Level:
X-Spam-Status: No, score=-111.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHP1eEvVo8-P for <plasma@ietfa.amsl.com>; Wed, 26 Oct 2011 15:03:49 -0700 (PDT)
Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8568621F85F1 for <plasma@ietf.org>; Wed, 26 Oct 2011 15:03:49 -0700 (PDT)
Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.2.247.0; Wed, 26 Oct 2011 15:03:49 -0700
Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by DF-H14-01.exchange.corp.microsoft.com ([157.54.78.139]) with mapi id 14.02.0202.004; Wed, 26 Oct 2011 15:03:49 -0700
From: Trevor Freeman <trevorf@exchange.microsoft.com>
To: Leif Johansson <leifj@mnt.se>, "plasma@ietf.org" <plasma@ietf.org>
Thread-Topic: [plasma] Levels of assurance
Thread-Index: AcyTRx6pnTp5VUnTRUe7DOXMw+3LyQApakYAAA76ewA=
Date: Wed, 26 Oct 2011 22:03:47 +0000
Message-ID: <E545B914D50B2A4B994F198378B1525D42734DD5@DF-M14-12.exchange.corp.microsoft.com>
References: <DFE85D7EFA640D4886E9A9141AEBCD200A097BE5@HDXDSP11.us.lmco.com> <4EA7B8B6.2070608@mnt.se>
In-Reply-To: <4EA7B8B6.2070608@mnt.se>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.100]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [plasma] Levels of assurance
X-BeenThere: plasma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." <plasma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plasma>, <mailto:plasma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/plasma>
List-Post: <mailto:plasma@ietf.org>
List-Help: <mailto:plasma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plasma>, <mailto:plasma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Oct 2011 22:03:50 -0000
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: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Leif Johansson Sent: Wednesday, October 26, 2011 12:37 AM To: plasma@ietf.org 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 plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma
- [plasma] Levels of assurance Fitch, Scott C
- Re: [plasma] Levels of assurance Leif Johansson
- Re: [plasma] Levels of assurance Trevor Freeman
- Re: [plasma] Levels of assurance Trevor Freeman