Re: [plasma] [abfab] FW: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime (plasma) bof discussion list

Josh Howlett <> Tue, 08 February 2011 10:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F39E3A70D2 for <>; Tue, 8 Feb 2011 02:26:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NV3i2uMwNWkA for <>; Tue, 8 Feb 2011 02:26:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2D35C3A70D0 for <>; Tue, 8 Feb 2011 02:26:54 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Email Security Appliance) with SMTP id A94F54A6B72_D511A73B for <>; Tue, 8 Feb 2011 10:26:59 +0000 (GMT)
Received: from ( []) by (Sophos Email Appliance) with ESMTP id 7C9AC4A6B71_D511A73F for <>; Tue, 8 Feb 2011 10:26:59 +0000 (GMT)
Received: from ([]) by EXC001 ([]) with mapi id 14.01.0218.012; Tue, 8 Feb 2011 10:27:20 +0000
From: Josh Howlett <>
To: "" <>
Thread-Topic: [abfab] FW: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime (plasma) bof discussion list
Thread-Index: AQHLxLycoN3Dez2g2UeJkPb7uChTz5P3aZNA
Date: Tue, 08 Feb 2011 10:27:20 +0000
Message-ID: <55DC663C2F4F9F439F23543E0078E8B30A6D3B@EXC001>
References: <> <> <005701cbc4bf$4ba0fb30$e2e2f190$>
In-Reply-To: <005701cbc4bf$4ba0fb30$e2e2f190$>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/mixed; boundary="_002_55DC663C2F4F9F439F23543E0078E8B30A6D3BEXC001_"
MIME-Version: 1.0
Cc: Josh Howlett <>
Subject: Re: [plasma] [abfab] FW: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime (plasma) bof discussion list
X-Mailman-Version: 2.1.9
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: Tue, 08 Feb 2011 10:26:55 -0000

Thank you. After a quick review of your docs, my sense is that Abfab could make sense in your scenarios.

If I have understood you correctly, I think you are suggesting refactoring Schaad-eps-trust such that it can use alternative bindings: WS-Trust or AAA.

I'm still undecided whether we are best served using a general purpose AAA-XML attribute, or domain-specific AAA-SAML and AAA-PLASMA attributes. They both share certain requirements of the AAA layer.

The consideration that weighs most in my mind is the implementation implications of a general purpose XML attributes. We definitely don't want to require AAA proxies to parse the attribute's XML blob to determine the next hop.

However, there's a similar issue in the AAA-SAML case where AAA proxies need to disambiguate between different types of SAML Issuers. I have suggested (see attached) using standard function-specific identifiers in the AAA Network Access Identifier. So, PLASMA could perhaps also define an identifier(s) that provide the necessary routing cue(s).


JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

--- Begin Message ---
>     >> Control question for Sam and Scott: is it possible (and
>     >> reasonably easy) to do SP-centric attribute aggregation for
>     >> abfab, by which I mean having the SP issue additional attribute
>     >> queries to IdPs within the AAA-centric trust model proposed by
>     >> Sam and Josh?
>     Josh> Yes, possible and easy (assuming, obviously, we can assume
>     Josh> that the SPs and IdP have a common identifier for the
>     Josh> subject).
> Josh, I suspect you are right, but the details are not clear to me.

Nor me in truth; I suspect that I am about to discover it was inadvisable of me to claim 'easy' :-)

> How does the SP address the request to a particular AA?

The model that I have in mind is that we specify a set of standard endpoint locator names for different type of Issuer roles. These can be used, in conjunction with the NAI realm of the Issuer, to construct a complete NAI.

e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0 attribute authority. An SP wanting to route a message to this actor to prefixes the realm of the intended Issuer with this, thus "". The AAA SAML attribute within this request message contains a SAML Request message containing the identifier for the subject.

--- End Message ---