RE: [KAML] Reminder: BOF proposals to me by October 1

"Josh Howlett" <> Mon, 19 November 2007 11:23 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1Iu4in-0008AX-FK; Mon, 19 Nov 2007 06:23:21 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1Iu4il-000890-5c for; Mon, 19 Nov 2007 06:23:19 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1Iu4ih-0002eW-U9 for; Mon, 19 Nov 2007 06:23:19 -0500
Received: from ([]) by with esmtp (Exim 4.50) id 1Iu4ic-0005NC-61; Mon, 19 Nov 2007 11:23:10 +0000
Received: from (localhost.localdomain []) by localhost (Email Security Appliance) with SMTP id 58DCC4A6B1A; Mon, 19 Nov 2007 11:18:47 +0000 (GMT)
Received: from ( []) by (Email Security Appliance) with ESMTP id 41EA84A6B14; Mon, 19 Nov 2007 11:18:43 +0000 (GMT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [KAML] Reminder: BOF proposals to me by October 1
Date: Mon, 19 Nov 2007 11:23:11 -0000
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [KAML] Reminder: BOF proposals to me by October 1
Thread-Index: AcgorW6JYnCaGO17StmlsGtDXLqEIQB6O8bA
References: <><><><> <>
From: "Josh Howlett" <>
To: "Tom Scavo" <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: Josh Howlett <>,, Paul Rabinovich <>
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 Nov 16, 2007 5:54 PM, Josh Howlett <> wrote:
> > >
> > > With regard to (1), I think you're missing the point, Josh.
> > > How the LoA is carried in the SAML assertion is a 
> technical detail, 
> > > not a matter of policy.
> >
> > My point was that if the <LoA token> can be acquired post 
> hoc then the 
> > Relying Party can decide itself what is the necessary 
> token(s), rather 
> > than relying on the TGS to choose what it believes is 
> appropriate. The 
> > fire-and-forget approach does not provide room for agility.
> I don't believe it works that way, Josh.  An RP that resolves 
> a token reference receives the same token that would 
> otherwise be received by value.  The act of authentication 
> has already taken place, so there is very little wiggle room, 
> in fact.  You may as well push the token up front in that case.

Aaaah, I now understand how we're getting our wires crossed.

I wasn't suggesting binding an artifact to the ticket; instead, I was
assuming that the RP is wielding a NameID (bound to the ticket) that can
be used, for example, as the <Subject> of an <AuthnQuery>; the AuthN
context may then be returned within an Authentication Statement.

(I think that dereferencing an artifact in this context is possibly
difficult for other reasons, but that's another discussion...)

FWIW, another reason that 'push' might be problematic is that the Ticket
Granting Service may not be aware of the authentication context owing to
the fact that the Authentication Service (in the Kerberos context!) that
the principal authenticates against may be a separate entity from the
TGS; how, therefore, does the TGS learn of the AuthN context from the
AS? You could signal this in the TGT perhaps, but this is adding

Further, if we assume that the Authentication Service is issuing the
Authentication Assertion (with the LoA) then some other possible issues
resolve themselves; for example, we know that we can set the value of
the NotOnOrAfter attribute to the expiry of the principal's Kerberos


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 Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

KAML mailing list