Re: [plasma] Levels of assurance

Trevor Freeman <> Wed, 26 October 2011 22:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 906EE21F8B6D for <>; Wed, 26 Oct 2011 15:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -111.099
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jHP1eEvVo8-P for <>; Wed, 26 Oct 2011 15:03:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8568621F85F1 for <>; Wed, 26 Oct 2011 15:03:49 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 26 Oct 2011 15:03:49 -0700
Received: from ([fe80::7c94:4036:120:c95f]) by ([]) with mapi id 14.02.0202.004; Wed, 26 Oct 2011 15:03:49 -0700
From: Trevor Freeman <>
To: Leif Johansson <>, "" <>
Thread-Topic: [plasma] Levels of assurance
Thread-Index: AcyTRx6pnTp5VUnTRUe7DOXMw+3LyQApakYAAA76ewA=
Date: Wed, 26 Oct 2011 22:03:47 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [plasma] Levels of assurance
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


-----Original Message-----
From: [] On Behalf Of Leif Johansson
Sent: Wednesday, October 26, 2011 12:37 AM
Subject: Re: [plasma] Levels of assurance

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]


	Cheers Leif
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -

plasma mailing list