Well, that depends upon whether the assertion is signed or not. If not
signed, SubjectConfirmation is pretty useless as the presenter could
modify it anyway to say whatever they wanted it to say. If the
assertion is signed, only the producer can put this data in.
However, that *only* applies to the Assertion itself. When Party A
communicates with RPA, it sends a message, a part of which is is the
assertion, but other data is sent as well and in this other data, Party
A can add the information, if any, that is required to meet the
requirements of the SubjectConfirmation (I want to say "conditions", but
there's another element called Conditions, so I don't want to confuse
things -- probably shouldn't have even said that).
Note that with the Browser SSO, Party A is a pretty dumb thing (from
many points of view) and isn't able to do very much on the message to
RPA (in fact it simply reflects data sent from the IdP in a
browser-redirect or Post message), so the confirmation will simply be
"...:cm:bearer").
Conor
------_=_NextPart_001_01C5E5FB.A4BB9DD4
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>
<META content=3D"MSHTML 6.00.2800.1522" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
many thanks for this,</FONT></SPAN></DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>though=20
is not 100% clear I think with your explanation I got most of=20
it.</FONT></SPAN></DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
definitely *now* (thanks to you) understand the SSO case and the bearer=20
Method.</FONT></SPAN></DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>Where=20
I find a little bit confuse is the other cases (like holder=20
Key).</FONT></SPAN></DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>AP=20
could include a HolderKey confirmation method + key.</FONT></SPAN></DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>This=20
means that the Party A should prove somehow that he holds that key (by=20
enc/decryp a message or the NameID itself or by any other mean) with the =
RP.</FONT></SPAN></DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>(this=20
where it gets a little bit confuse, how the PartyA proves he holds the=20
key)</FONT></SPAN></DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
guess though this must be out of the scope of SAML. (if you have an =
example it=20
would be helpful)</FONT></SPAN></DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>For=20
the Subject in the Confirmation, sorry I didn't mean subject but=20
BaseID/NameID/Enc...ID instead. They are present at the Subject level as =
well as=20
the SubjectConfirmation level.</FONT></SPAN></DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>But=20
looking at the schema I assume that those will be included in the =
confirmation=20
only if they are not present at the Subject=20
level.</FONT></SPAN></DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>Does=20
it make sense?</FONT></SPAN></DIV>
<DIV><SPAN class=3D176251713-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>
<P><FONT color=3D#0000ff size=3D1></P></FONT><FONT size=3D1></FONT><FONT =
color=3D#0000ff=20
size=3D1><</FONT><FONT color=3D#800000 size=3D1>element</FONT><FONT =
color=3D#ff0000=20
size=3D1> name</FONT><FONT color=3D#0000ff size=3D1>=3D"</FONT><FONT=20
size=3D1>SubjectConfirmation</FONT><FONT color=3D#0000ff =
size=3D1>"</FONT><FONT=20
color=3D#ff0000 size=3D1> type</FONT><FONT color=3D#0000ff =
size=3D1>=3D"</FONT><FONT=20
size=3D1>saml:SubjectConfirmationType</FONT><FONT color=3D#0000ff=20
size=3D1>"/></DIV>
<DIV></FONT><FONT size=3D1>
<P></FONT><FONT color=3D#0000ff size=3D1><</FONT><FONT =
color=3D#800000=20
size=3D1>complexType</FONT><FONT color=3D#ff0000 size=3D1> =
name</FONT><FONT=20
color=3D#0000ff size=3D1>=3D"</FONT><FONT =
size=3D1>SubjectConfirmationType</FONT><FONT=20
color=3D#0000ff size=3D1>"></P></FONT><FONT size=3D1>
<P></FONT><FONT color=3D#0000ff size=3D1><</FONT><FONT =
color=3D#800000=20
size=3D1>sequence</FONT><FONT color=3D#0000ff =
size=3D1>></P></FONT><FONT size=3D1>
<P></FONT><FONT color=3D#0000ff size=3D1><</FONT><FONT =
color=3D#800000=20
size=3D1>choice</FONT><FONT color=3D#ff0000 size=3D1> =
minOccurs</FONT><FONT=20
color=3D#0000ff size=3D1>=3D"</FONT><FONT size=3D1>0</FONT><FONT =
color=3D#0000ff=20
size=3D1>"></P></FONT><FONT size=3D1>
<P></FONT><FONT color=3D#0000ff size=3D1><</FONT><FONT =
color=3D#800000=20
size=3D1>element</FONT><FONT color=3D#ff0000 size=3D1> ref</FONT><FONT =
color=3D#0000ff=20
size=3D1>=3D"</FONT><FONT size=3D1>saml:BaseID</FONT><FONT =
color=3D#0000ff=20
size=3D1>"/></P></FONT><FONT size=3D1>
<P></FONT><FONT color=3D#0000ff size=3D1><</FONT><FONT =
color=3D#800000=20
size=3D1>element</FONT><FONT color=3D#ff0000 size=3D1> ref</FONT><FONT =
color=3D#0000ff=20
size=3D1>=3D"</FONT><FONT size=3D1>saml:NameID</FONT><FONT =
color=3D#0000ff=20
size=3D1>"/></P></FONT><FONT size=3D1>
<P></FONT><FONT color=3D#0000ff size=3D1><</FONT><FONT =
color=3D#800000=20
size=3D1>element</FONT><FONT color=3D#ff0000 size=3D1> ref</FONT><FONT =
color=3D#0000ff=20
size=3D1>=3D"</FONT><FONT size=3D1>saml:EncryptedID</FONT><FONT =
color=3D#0000ff=20
size=3D1>"/></P></FONT><FONT size=3D1>
<P></FONT><FONT color=3D#0000ff size=3D1></</FONT><FONT =
color=3D#800000=20
size=3D1>choice</FONT><FONT color=3D#0000ff=20
size=3D1>></P></FONT></FONT></SPAN></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Conor P. Cahill=20
[mailto:concahill@aol.com] <BR><B>Sent:</B> 10 November 2005=20
12:46<BR><B>To:</B> Sarno, Giuseppe [MOP:GM15:EXCH]<BR><B>Cc:</B>=20
saml-dev@lists.oasis-open.org<BR><B>Subject:</B> RE: [saml-dev] =
Subject=20
confirmation.<BR><BR></FONT></DIV><FONT face=3D"Comic Sans =
MS,sans-serif"><FONT=20
size=3D2><BR><BR><SPAN type=3D"cite">Giuseppe Sarno wrote on =
11/10/2005, 5:10=20
AM:</SPAN> </FONT></FONT>
<P><FONT face=3D"Comic Sans MS,sans-serif" size=3D2></FONT></P>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin =
solid"=20
type=3D"cite"><FONT face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>A bit=20
confused,</FONT></SPAN></FONT></DIV><FONT face=3D"Comic Sans =
MS,sans-serif"=20
size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005></SPAN></FONT> </DIV><FONT=20
face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>So subject=20
confirmation is not really a mean to confirm that the Subject is =
correct (in=20
a way).</FONT></SPAN></FONT></DIV></BLOCKQUOTE><FONT size=3D2><FONT=20
face=3D"Comic Sans MS,sans-serif">That's correct. It's to =
confirm that the=20
entity that is able to meet the requirements of the confirmation are =
allowed=20
to act as that Subject.</FONT></FONT><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin =
solid"=20
type=3D"cite"><FONT face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>But then why=20
assigning this data to the Subject=20
mmmmhhh....</FONT></SPAN></FONT></DIV></BLOCKQUOTE><FONT =
size=3D2><FONT=20
face=3D"Comic Sans MS,sans-serif">Well it has to go somewhere although =
with the=20
concept of subjectless assertions (which there was some discussion =
about),=20
perhaps it should be elsewhere. However, I think the real =
reasons is=20
that in SAML 1.x there were multiple subjects, one in each statement =
and so=20
you could possibly have a single assertion with different subjects =
having=20
different confirmations. That isn't the case any more, but I =
think the=20
confirmation data still stayed with the subject.<BR><BR>I would also =
say that=20
while I prefer to think of this as to what the presenter needs to do =
to=20
present the assertion, others would say that it has little to do with =
the=20
assertion but is all about the subject (of course, in any case, if you =
can't=20
meet at least one of the confirmations in the subject, you aren't =
supposed to=20
accept the assertion, so I don't think the difference matters=20
much).<BR></FONT></FONT>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin =
solid"=20
type=3D"cite"><FONT face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>Also there is=20
a Subject element also within the Subject confirmation, what is this =
for=20
?</FONT></SPAN></FONT></DIV></BLOCKQUOTE><FONT size=3D2><FONT=20
face=3D"Comic Sans MS,sans-serif">I don't think there is (at least I =
don't see=20
it in the core spec -- what line in what spec do you see this =
on?). =20
</FONT></FONT><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin =
solid"=20
type=3D"cite"><FONT face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005></SPAN></FONT> </DIV><FONT=20
face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>So I'll make=20
an example to see whether I got the =
point:</FONT></SPAN></FONT></DIV><FONT=20
face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>I will avoid=20
talking about SP,and IDP.</FONT></SPAN></FONT></DIV><FONT=20
face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005></SPAN></FONT> </DIV><FONT=20
face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>- PartyA (it=20
might not be a browser) tries to access RelyingPartyA=20
(RPA). =20
</FONT></SPAN></FONT></DIV><FONT face=3D"Comic Sans MS,sans-serif"=20
size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005></SPAN><SPAN =
class=3D473174409-10112005><FONT=20
face=3DArial color=3D#0000ff size=3D2>- PartyA queries (or ask for=20
auth) AssertingParty(AP) for an Assertion.=20
</FONT></SPAN></FONT></DIV><FONT face=3D"Comic Sans MS,sans-serif"=20
size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>(I'm assuming=20
in a generic case is not the RP to query the AP but it could be =
the=20
PartyA also to get hold of an assertion. Is this a correct=20
=
assumption?) &=
nbsp; </FONT></SPAN></FONT></DIV=
><FONT=20
face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005></SPAN><SPAN=20
class=3D473174409-10112005></SPAN></FONT> </DIV><FONT=20
face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>- AP generate=20
an assertion. </FONT></SPAN></FONT></DIV><FONT=20
face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005></SPAN></FONT> </DIV><FONT=20
face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>Now who=20
should produce the confirmation ? AP or PartyA=20
?</FONT></SPAN></FONT></DIV></BLOCKQUOTE><FONT size=3D2><FONT=20
face=3D"Comic Sans MS,sans-serif">The <SubjectConfirmation> =
element is=20
*always* built by the AP when they build the =
assertion. =20
Party A, when looking at the assertion sees what they are supposed to =
do and=20
they meet the requirments of the <SubjectConfirmation> on the =
message to=20
the RPA. The RPA, upon receiving the message which includes the=20
assertion, verifies that Party A has done the required "things" based =
upon the=20
<SubjectConfirmation> before they accept/trust the =
assertion.<BR><BR>You=20
can look at SubjectConfirmation as a message from the AP to the RPA =
saying=20
"Party A needs to do this 'stuff' to use the assertion with=20
you".<BR></FONT></FONT>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin =
solid"=20
type=3D"cite"><FONT face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005></SPAN></FONT> </DIV><FONT=20
face=3D"Comic Sans MS,sans-serif" size=3D2></FONT>
<DIV><FONT face=3D"Comic Sans MS,sans-serif" size=3D2><SPAN=20
class=3D473174409-10112005><FONT face=3DArial color=3D#0000ff =
size=3D2>From what I=20
understood in theory they Both could provide a =
confirmation. Is=20
this right ? or only the producer can touch the assertion=20
?</FONT></SPAN></FONT></DIV></BLOCKQUOTE><FONT size=3D2><FONT=20
face=3D"Comic Sans MS,sans-serif">Well, that depends upon whether the =
assertion=20
is signed or not. If not signed, SubjectConfirmation is pretty =
useless=20
as the presenter could modify it anyway to say whatever they wanted it =
to=20
say. If the assertion is signed, only the producer can put this =
data=20
in.<BR><BR>However, that *only* applies to the Assertion itself. =
When=20
Party A communicates with RPA, it sends a message, a part of which is =
is the=20
assertion, but other data is sent as well and in this other data, =
Party A can=20
add the information, if any, that is required to meet the requirements =
of the=20
SubjectConfirmation (I want to say "conditions", but there's another =
element=20
called Conditions, so I don't want to confuse things -- probably =
shouldn't=20
have even said that).<BR><BR>Note that with the Browser SSO, Party A =
is a=20
pretty dumb thing (from many points of view) and isn't able to do very =
much on=20
the message to RPA (in fact it simply reflects data sent from the IdP =
in a=20
browser-redirect or Post message), so the confirmation will simply be=20
=
"...:cm:bearer").<BR><BR><BR>Conor<BR></BLOCKQUOTE></FONT></FONT></BODY><=
/HTML>
------_=_NextPart_001_01C5E5FB.A4BB9DD4--
|