Summary of players in SSO and client/proxy use cases

[Scott Cantor <cantor.2@osu.edu>]

If it helps frame discussion and perhaps scoping, I tried to break down the
inputs Ron proposed by use case (or my interpretation of them anyway).

------

AuthnRequest in the "traditional" SSO/ID-FF use case:

1. the entity requesting the assertion

SP, <Issuer>, may be authenticated using simple message signature or by
passing message signed by WSS via a SOAP intermediary, or could be
unauthenticated because of nature of SSO protocol.

2. the entities able to use the returned assertion.

Default is for this to be only the immediate sender, can authenticate via
any means supported by chosen binding. Could specify other entities (such as
the SP) as a means of getting an impersonation assertion during SSO, but
would need a way of implicitly or explicitly including the message sender in
this list since the typical case is for an assertion usable only by message
sender as a bearer token.

3. the subject of the returned assertion.

The immediate sender, can authenticate via any supported means. Requester
does not know who the subject is in most cases, but could imagine that
during a reauthentication operation, the SP might explicitly reference the
subject for some reason.

4. the target services (audiences?) at which the assertion may be used

By default, the requester (SP) is one. Others as specified to constrain
forwardability of assertion.

------

AuthnRequest in the "client" or "proxy" use cases presented by the Kerberos
and SOAP solution proposals:

1. the entity requesting the assertion

<Issuer>, can authenticate via any means supported by binding.

2. the entities able to use the returned assertion.

Default is for this to be the sender/requester, can authenticate via any
means supported by binding. Could specify other entities as a means of
getting an assertion usable at other hops without extra work but this is
just an optimization.

3. the subject of the returned assertion.

Default is for this to be the immediate sender/requester, can authenticate
via any supported means. But could be an arbitrary subject if the requester
is asking to impersonate subject. Permission to do this may depend on
presenting additional security tokens of various sorts that demonstrate
relationship to subject. Need to work through examples of this as well as
how impersonation would be expressed.

4. the target services (audiences?) at which the assertion may be used

As specified by requester.


-- Scott, hoping I'm helping with all these emails and not just making a
mess