----- Original Message -----
Sent: Thursday, August 09, 2001
19:40
Subject: Assertion id AND attributes in
the same query
Colleagues - The need to convey an assertion id and attributes
in the same query arises in the following circumstances.
A browser contacts a content site and is redirected to an
authentication site. The content site has specific requirements
for:
1. The authentication scheme between the browser and the
authentication site (I'll call this "primary" authentication);
2. The authentication scheme between the browser and the
content site upon its return to the content site (I'll call this "secondary"
authentication, normally this would be a bearer token, but who
knows?);
3. The space in which the subject's name should appear;
and
4. User attributes.
So, the content site needs to communicate its requirements in
these four areas to the authentication site, preferably, before primary
authentication takes place.
There is currently no fully-specified way for the content site
to communicate its needs to the authentication site. What are the
possible solutions?
1. The authentication site "just knows" what authentication
schemes, namespaces and attributes the content site needs.
2. Each authentication site URL corresponds to a single
authentication scheme. Then the content site specifies the
authentication scheme by redirecting the browser to the appropriate
URL.
3. The authentication site returns assertions containing every
authentication scheme, namespace and additional attribute, and the content
site searches through them for the ones that suit its needs.
4. The authentication site returns its own choice of
authentication assertion and the content site submits a further query for any
additional, or alternative, assertions that it needs.
Solution 1 works because we don't.
Solution 2 addresses requirement 1, but not requirements 2, 3
and 4.
Solution 3 is unsatisfactory from an identity-theft/privacy
point of view.
Solution 4 introduces more delay than is absolutely
necessary.
We have, in both the "fat object" and "artifact" browser
profiles, opportunities to solve these questions in a more satisfactory
manner.
In the "fat object" profile, the "form" can contain the
Assertion Queries. In the "artifact" profile, the initial redirection by
the content site to the authentication site can contain an artifact, in the
redirection URL, corresponding to the Assertion Queries, using either of the
push or pull communication models. The thing that is new and surprising
about this approach is that the artifact does not correspond to an
"assertion", but to a "query". There would then have to be a
communication directly between the content and authentication sites in which
the content site would request assertions that directly meet its
needs.
This is what it looks like in both the "push" and "pull"
models.
Push model
Browser
Content site
Authentication site
1 <---- redirect(artifact1) ----
2
--------------------- redirect(artifact1)--------------->
3
---- query(artifact1) ---->
4
<----------------------- authenticate ------------------>
5
<- assertions(artifact2) --
6
<-----------------------------------redirect(artifact2)--
7 -------redirect(artifact2)--->
Pull model
Browser
Content site
Authentication site
1 <---- redirect(artifact1) ----
2
--------------------- redirect(artifact1) --------------->
3 <------------------------ authenticate ------------------>
4
<- request query(artifact1) -
5
----- query(artifact2) ----->
7
<-------- assertions --------
6
<-------------------- redirect(artifact2) ----------------
7 -----redirect(artifact2)---->
Line 3 of the push model and line 5 of
the pull model involve a query with both an artifact (or assertion id) and the
set of requested attributes.
Best regards. Tim.
------------------------------------------------------------------------
---------------
Tim Moses
Tel: 613.270.3183