Prateek,
Our reason for incuding it was this statement mentioned in the bindings
document that the " <ConfirmationMethod> will often
be accompanied with some piece of informattion such as a certificate
or key in the <SubjectConfirmationData> and/or <ds:KeyInfo>
elements, which will allow the relying party to perform the necessary
check". So our logical conclusion was that the
only data we have along with ConfirmationMethod of artifact URI was
its value, so we put it in <SubjectConfirmationData>
I dont see any clear mention of the fact that the there should be NO
relationship between artifact and assertion in web artifact
profile. Am I missing it ?
In anycase we need to have a common agreement about this in order to
interoperate. If all decide that we should not
have it, we should not .
Thanks
Bhavna
"Mishra, Prateek" wrote:
Ryan,you
are referring to ConfirmationMethod, which you correctly point out must
be set to the"artifact" URI. Bhavna
and Rob referred to SubjectConfirmationData, a different animal (element)
altogether. Their questionwas whether
the SubjectConfirmationData should carry the corresponding artifact value.
I don't think it shouldand we do
not include it as part of the assertion. Part
of the confusion here stems from similar sounding names: notice that the
SubjectConfirmation elementhas sub-elements
ConfirmationMethod and SubjectConfirmationData. The former is required
but not the latter.-
prateek
Prateek,Page
17 of the bindings spec. establishes a relationship between the fact that
an artifact was used and the assertion by requiring that the ConfirmationMethod
of the SSO assertion be urn:oasis:names:tc:SAML:1.0:cm:artifact-01."The
<saml:ConfirmationMethod> element of each assertion MUST be set to urn:oasis:names:tc:SAML:1.0:cm:artifact-01."This
isn't the same thing as a relationship between the specific artifact and
assertion, but I think it's strong enough to invalidate that there is no
relationship.If
this relationship isn't required, why is the ConfirmationMethod specified?Ryan
Folks,this
is an issue. We do not use confirmation data, nor do we check for it inthe
artifact case.Nowhere
in the artifact browser profile description is there a requirement that ConfirmationData
be used. Indeed, one key requirement in developing the artifactprofile
was that there be NO relationship between the artifact and the assertion
itself. By placingthe artifact in
the assertion (as conf data) this requirement is violated (however weakly). The
relationship between the artifact and the assertion is established via
bilateral authenticationbetween source
and destination sites. There is no other relationship required.-
prateek
The
Oblix SAML implementation also expects the artifact confirmation data.--
Charles
Yes, we at Sun need the SubjectConfirmaData to be the associated attifact
string. The source site at our end checks that the SubjectConformationData
does
contain the artifact string sent out originally in the query to the
destination's soap responder.
Bhavna
"Philpott, Robert" wrote:
The
specs aren't really clear on this... Do folks expect to receive a ConfirmationData
element containing the artifact as part of the SubjectConfirmation when
using the Artifact-01 method?
I've
seen a sample assertion that did have it and one that didn't.
I
assume you would want it so the relying party could (if they so desire)
verify the assertion statements are associated with a particular artifact-based
request.
Thanks,
Rob
Philpott
RSA
Security Inc.
The
Most Trusted Name in e-Security
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:rphilpott@rsasecurity.com
--
________________________________________________________________________
Bhavna Bhatnagar Sun Microsystems Inc.
Identity Management group __o
Tel: 408-276-3591 _`\<,_
(*)/ (*)
________________________________________________________________________
--
________________________________________________________________________
Bhavna Bhatnagar Sun Microsystems Inc.
Identity Management group __o
Tel: 408-276-3591 _`\<,_
(*)/ (*)
________________________________________________________________________
|