Subject: [abfab] SAML Request/Response

From: "Jim Schaad" <[email-masked]>
Date: Sun, 20 Nov 2011 13:50:59 -0800

Josh,

You said something at the last meeting that took me a couple of days to
process and figure out that I might have some type of problem.  I really
would like to be able to send SAML request messages after the EAP has
completed. However there are situations where it might not be feasible and I
think this needs to be discussed.

If the acceptor is not told the identity of the client, then it would be
unable to send a SAML request at a later point in time.   If the request is
sent along with the EAP conversation, then the EAP server knows the identity
of the client.  However after the EAP conversation has finished, I would not
expect the EAP server to send a state token to allow for a continuation of
the conversation.  

In order to deal with this case, it may be that the EAP server will need to
provide an anonymous identity to the acceptor that it can later correlate
back to the actual identity of the client.  Such a provider could be an
encrypted token.

Jim

---

From: Josh Howlett <[email-masked]>
Date: Mon, 21 Nov 2011 08:28:00 +0000

Jim,

>back to the actual identity of the client.  Such a provider could be an

SAML defines a pseudonymous identifier intended for this use case. This
vale would be returned to the acceptor at the end of the Abfab
Authentication Profile in a SAML authentication assertion. The acceptor
could subsequently use this value to name the subject in a subsequent
Abfab Assertion Request. Does that work for your use case?

Josh.

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Nov 2011 10:43:09 -0500

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> In order to deal with this case, it may be that the EAP server
    Jim> will need to provide an anonymous identity to the acceptor that
    Jim> it can later correlate back to the actual identity of the
    Jim> client.  Such a provider could be an encrypted token.

Right.

I think this is the way to handle later attribute queries.