["Conor P. Cahill" <concahill@aol.com>]

Giuseppe Sarno wrote on 11/10/2005, 5:10 AM:

A bit confused,

 

So subject confirmation is not really a mean to confirm that the Subject is correct (in a way).

That's correct. 
It's to confirm that the entity that is able to meet the requirements
of the confirmation are allowed to act as that Subject.

But then why assigning this data to the Subject mmmmhhh....

Well it has to go
somewhere although with the concept of subjectless assertions (which
there was some discussion about), perhaps it should be elsewhere. 
However, I think the real reasons is that in SAML 1.x there were
multiple subjects, one in each statement and so you could possibly have
a single assertion with different subjects having different
confirmations.  That isn't the case any more, but I think the
confirmation data still stayed with the subject.

I would also say that while I prefer to think of this as to what the
presenter needs to do to present the assertion, others would say that
it has little to do with the assertion but is all about the subject (of
course, in any case, if you can't meet at least one of the
confirmations in the subject, you aren't supposed to accept the
assertion, so I don't think the difference matters much).

Also there is a Subject element also within the Subject confirmation, what is this for ?

I don't think
there is (at least I don't see it in the core spec -- what line in what
spec do you see this on?).

 

So I'll make an example to see whether I got the point:

I will avoid talking about SP,and IDP.

 

- PartyA (it might not be a browser) tries to access RelyingPartyA (RPA).          

- PartyA queries (or ask for auth) AssertingParty(AP) for an Assertion.

(I'm assuming in a generic case is not the RP to query the AP but it could be the PartyA also to get hold of an assertion. Is this a correct assumption?)                  

 

- AP generate an assertion. 

 

Now who should produce the confirmation ? AP or PartyA ?

The
<SubjectConfirmation> element is *always* built by the AP when
they build the assertion.    Party A, when looking at the assertion
sees what they are supposed to do and they meet the requirments of the
<SubjectConfirmation> on the message to the RPA.  The RPA, upon
receiving the message which includes the assertion, verifies that Party
A has done the required "things" based upon the
<SubjectConfirmation> before they accept/trust the assertion.

You can look at SubjectConfirmation as a message from the AP to the RPA
saying "Party A needs to do this 'stuff' to use the assertion with you".

 

From what I understood in theory they Both could provide a confirmation. Is this right ? or only the producer can touch the assertion ?

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