Re: [KAML] Re: Chicago bar-BOF summary

"Tom Scavo" <> Thu, 06 September 2007 20:03 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1ITNZj-00023a-DZ; Thu, 06 Sep 2007 16:03:39 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1ITNZi-00023T-Qd for; Thu, 06 Sep 2007 16:03:38 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1ITNZh-0000xv-JI for; Thu, 06 Sep 2007 16:03:38 -0400
Received: by with SMTP id 31so77620huc for <>; Thu, 06 Sep 2007 13:03:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=rwmatJ3SQ/pQN6bO4hIbvhR0qbqIvvNB0yy9VPhVFk8=; b=hjVbQrdypjVdMM603x76Opa1dyNoIxQumZdgu+RUUK/nKaknU/uMFoKc3fn2gQB25H9k4yq3xTyGqgZLpykEfTCAgGDpK/MC+SMzoewbivbiRjopcyCAfpHeyx/Fzzt29WzX0Br3enBtz24Z16BNdaAmOn1CAMfKWxJWmZ1FqDA=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GHufE1c5QtuEigtrpxMdJ7s6kB0WMWnx/NOP3hv5TvOPsAkt9mW/fZpSa7MompB5yuZFBdXJceBsqtbM7xtPuZPpa51W/Y0Oixjf3YpGD9L4Xq44J+KxM16PiLdBvdJ6jFen0Lpn7cz1t15n2MDWnXOtXe2ngxnTTuwEbrPP6Fs=
Received: by with SMTP id i19mr1578177bue.1189109016282; Thu, 06 Sep 2007 13:03:36 -0700 (PDT)
Received: by with HTTP; Thu, 6 Sep 2007 13:03:36 -0700 (PDT)
Message-ID: <>
Date: Thu, 6 Sep 2007 16:03:36 -0400
From: "Tom Scavo" <>
To: "Henry B. Hotz" <>
Subject: Re: [KAML] Re: Chicago bar-BOF summary
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <> <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about SAML and Kerberos intersections <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On 9/6/07, Henry B. Hotz <> wrote:
> Or do we just start discussing how to put SAML tokens into the
> authorization data field and what constraints we impose on how the
> tokens are encrypted/validated.

FWIW, we are embedding SAML assertions in short-lived X.509
certificates and using the latter as decorated authentication tokens
in grids.  The SAML assertions (not responses or other SAML protocol
constructs) contain authentication and attribute information used for
access control purposes.  A big advantage of this approach (we think)
is that the SAML goes along for the ride regardless of how the X.509
certificate is presented to the relying party, either TLS or some
message-level protocol such as WS-Security X.509 Token Profile.

Use cases are varied.  The presenter may be the subject or an entity
(such as a portal) acting on behalf of the subject.  The SAML
assertion may be issued by the same entity that issued the X.509
certificate (in which case the requirements on the SAML assertion are
minimal) or by some third party (in which case the assertion is a
signed, standalone token).

Tom Scavo

KAML mailing list