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

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

Prateek and I discussed this on the phone this last Tue. Our resolution is
inlined below (be sure to read to the end of the message). 

Note that this editorial issue again illustrates the need for cleaning up the
core-27 language describing ConfirmationMethod semantics. 

thanks,

JeffH

"Mishra, Prateek" wrote:
> 
> >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.
> 
> I don't follow this point. There is no issue of "future" here. 


So, given discussion below, line 647 et al of core-27 describing
ConfirmationMethod semantics needs to be cleaned up.

[See other msgs regarding this point, which are related to ISSUE:[DS-1-10:
SubjectConfirmation Descriptions] (line 1253 of saml-issues-08), and in this
msg..

New Issue: SubjectConfirmation descriptions
http://lists.oasis-open.org/archives/security-services/200201/msg00247.html

It is also related to this proposal by Hal for prose describing the differences
between AuthenticationMethod and ConfirmationMethod..

Proposed text: Authentication Method vs. SubjectConfirmation Met hod 
http://lists.oasis-open.org/archives/security-services/200202/msg00046.html
]

> Some
> user has shown up with an artifact at some site; the site now obtains
> the assertion associated with the artifact. Generally speaking, the
> confirmation method indicates the technique used to connect the assertion
> with the user. In this case, there is no technique specified and that is
> what the confirmation method element indicates. Further, it also indicates
> that the assertion must have been obtained by a lookup call from the source
> site.
> 
> >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?
> 
> This is correct. The point here is that assertions obtained via
> artifact lookup in the browser profile have a special status: they
> were obtained via the artifact browser profile and the confirmation
> method provides this information.

Ok. And, as we discussed on the phone, core-27 specifies
SubjectConfirmationData to accompany a ConfirmationMethod = "#artifact"
(core-27 lines 1555-1557)...

  <SubjectConfirmationData>: Base64 ( Artifact )
  The subject of the assertion is the party that can present the 
  SAML Artifact value specified in <SubjectConfirmationData>.


The semantics here we discussed are:

  This authentication assertion was obtained via the "Browser/Artifact 
  Profile of SAML". The artifact that was dereferenced to obtain this 
  assertion is contained in the SubjectConfirmationData. 



> >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?
> 
> Not at all. There is no such intent here.


Actually, I think it implicitly is, and this fits with the overall semantics of
ConfirmationMethod being how the relying party may in the future go about
authenticating the Subject. Tho I'm not suggesting we need to explicitly say
this. See the text Hal wrote about this in this msg..

Proposed text: Authentication Method vs. SubjectConfirmation Met hod 
http://lists.oasis-open.org/archives/security-services/200202/msg00046.html


> >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.
> 
> Jeff, I really dont see the confusion here. To me this feels
> like an editorial issue. If you would like to see an additional
> line added to lines 525-526, well and good, go ahead and propose
> the text.


So the change to make to bindings-model-11 is to change lines 525-526 of
bindings-model-11 to say..

  The <saml:ConfirmationMethod> element of each assertion MUST be set
  to the value specified in [SAMLCore] for "SAML Artifact", and the 
  <saml:SubjectConfirmationData> element MUST be present with its value
  being the SAML_artifact supplied to obtain the assertion.


there's an accompanying change to make to core-27 line 1556-1557 that I'll put
in another msg. 

---
end