Solution proposal for W-5: Enhanced SSO Profiles (Updated)

["Mishra, Prateek" <pmishra@netegrity.com>]

This work item deals with the replacement/enhancement of the SAML 1.1 web
browser profiles. It is a substantial and complicated enterprise that needs
to be approached in stages.

The SAML 1.1 web browser profiles are described entirely within the
profile/bindings document. A sequence of canonical HTTP interactions leads a
user from a "Source Site" to a "Destination Site". End of story.

ID-FF 1.2 describes the profiles with more structure and sophistication. The
protocols and schema document describes a pair of generic flows: one from
the "Service Provider" to the "Identity Provider", and a second flow that
reverses the order of providers. The bindings and profiles document next
"maps" these flows into concrete realizations, at least three of which we
plan to pursue in SAML 2.0: Browser Artifact, Browser POST, LECP.

PROPOSAL: 
1. The SSTC continue to work with the structure given in the ID-FF 1.2
materials. In other words, separate generic flows and schema extensions
required to support Web SSO and federation from specific technology
realizations.  

2. Further, the SSTC accept the materials in Section 3.2 of the ID-FF 1.2
Protocols and Schemas document, contingent upon any changes proposed by:

(1) W-2: Identity Federation
(2) W-2a: SSO with Attribute Exchange
(3) W-6: Proxied SSO
(4) W-8: Authentication Context

Note the following difference in approach between ID-FF 1.2 and SAML 1.1
realizations of an "authentication response":

(a) In ID-FF 1.2, each returned Assertion may contain an "InResponseTo"
element which must be set to the RequestID attribute of the original
<AuthNRequest>. Each individual assertion MUST be signed but the response as
a whole does not need to be signed.   

(b) In SAML 1.1, the "Response" element response includes a "InResponseTo"
element which must be set to the RequestID attribute of the original
request. Assertions carried within the response do not need to be signed.