[security-services] ISSUE: bindings-model-11: SSO Assertion'sConfirmationMethod set to SAMLArtifact?

[Jeff Hodges <Jeff.Hodges@sun.com>]

ISSUE: bindings-model-11: SSO Assertion's ConfirmationMethod set to
SAMLArtifact?

lines 525-526 of bindings-model-11 say..
  
  "The <saml:ConfirmationMethod> element of each assertion MUST be set to
   SAMLArtifact (see [SAMLCore])."


The semantics of this don't seem to make sense, since the assertion in this
case (termed an "SSO assertion" in bindings-model-11, lines 398-400), is
returned to the requester as a result of making a <saml:Request> containing
assertion artifacts in the <samlp:AssertionArtifact> element (lines 502-503). 

Now, core-27 states in line 647 that the definition of ConfirmationMethod is..

  A URI that identifies a protocol to be used to authenticate the subject.
                                   ^^^^^^^^^^

..and the dereferenced SAMLArtifact by definition *can't* be used to
"authenticate the subject" again in the future, because it is "one time use"
and was already used to obtain the assertion-cum-AuthenticationStatement. 

Is the purpose of requiring this use of SAMLArtifact in ConfirmationMethod
simply a way to ensure that
assertions-cum-AuthenticationStatements obtained via dereferencing of a
SAMLArtifact are flagged as such? 

And/or is the purpose to inform the requester that the way to AGAIN, in the
(near) future, authenticate the subject (perhaps to check session liveness), is
to (again) initiate Step 1 of "Browser/Artifact Profile of SAML" (line 437) by
redirecting the user's browser to the inter-site transfer service?

Either way, the language in bindings-model-11 should be cleand up and
augemented in order to clarify the purpose of having the ConfirmationMethod of
the returned assertions set to SAMLArtifact.

thanks,

JeffH