Re: [plasma] PEP Bootstrapping

Trevor Freeman <> Wed, 24 August 2011 21:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2FD621F8D65 for <>; Wed, 24 Aug 2011 14:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.226
X-Spam-Status: No, score=-110.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6FhKLXkHkTQ5 for <>; Wed, 24 Aug 2011 14:22:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C8E6D21F8D59 for <>; Wed, 24 Aug 2011 14:22:35 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 24 Aug 2011 14:23:47 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 24 Aug 2011 14:23:46 -0700
Received: from ([fe80::7c94:4036:120:c95f]) by ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.02.0202.002; Wed, 24 Aug 2011 14:23:46 -0700
From: Trevor Freeman <>
To: Jim Schaad <>, "'Fitch, Scott C'" <>, "" <>
Thread-Topic: [plasma] PEP Bootstrapping
Thread-Index: AcxS6Kpc0m214kCwTEuhM0dUX5InQwBT0VyAA5m5bJA=
Date: Wed, 24 Aug 2011 21:23:45 +0000
Message-ID: <>
References: <> <01b301cc53fd$77d3c3e0$677b4ba0$>
In-Reply-To: <01b301cc53fd$77d3c3e0$677b4ba0$>
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] PEP Bootstrapping
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, 24 Aug 2011 21:22:43 -0000

Hi Scott,

I think both the set of roles a user is able to assume and the set of polices a role can assert should follow the same PIP\PDP\PAP model. 

The PDP needs a set of information to compile the list of roles and the set of polices for each role. That information comes from either a local PIP  or as claims from remote PIP which the PDP trusts. The PDP can be aggregating information here from different PIPs e.g. multiple PIP can assert different policies belong to a role.

Equally under the same model I would expect the PAP to publish policy about other aspects of its policies such as who can use a policy or what the policy can be applied to, which the PDP  would enforce. 

The model is trying to ensure clean separation of responsibilities, information points publish "factual" information, policy comes from policy authorities and decisions and made by decision makes based on the policy and information presented. 


-----Original Message-----
From: [] On Behalf Of Jim Schaad
Sent: Friday, August 05, 2011 10:54 PM
To: 'Fitch, Scott C';
Subject: Re: [plasma] PEP Bootstrapping

> -----Original Message-----
> From: [] On 
> Behalf Of Fitch, Scott C
> Sent: Thursday, August 04, 2011 1:57 PM
> To:
> Subject: [plasma] PEP Bootstrapping
> I understand the importance of "bootstrapping" the Content Creation PEP.
> However, I'm not sure it's appropriate for the PDP to tell it its 
> roles as outlined in v02. It seems to me that role (and other related 
> information about the author) would come from the PIP and be delivered 
> to the PDP as part of the initial bootstrap and authentication 
> process. At that point,
> PDP could reply with the set of policies available to the user.

The model is operating under the impression that the "roles" an entity can assume is based not on configuration, but on application of policy information.  This means that it is not a configured property, which would make it appropriate for a PIP but is computed based on the properties obtained from the PIP and the policy configuration in the PDP.  

Does this make sense?  Is there something we can do to make this more clear?

> Retrieving the list of policies is itself essentially another access
> decision (i.e., what types of data is this user allowed to publish?). 
> So
it seems
> to make sense to follow the PEP/PIP/PDP model in this interaction too. 
> It
> allows for more flexibility in determining what policies to assign to 
> the
> beyond just Role-based access control decisions.

I believe this is what the document currently says.  Do you see a need for changes here?


> Scott Fitch
> Cyber Architect
> Lockheed Martin Enterprise Business Services
> _______________________________________________
> plasma mailing list

plasma mailing list