List Home All Archives Dates Threads Authors Subjects
saml-dev - RE: [saml-dev] Subject confirmation. Message Thread: Previous | Next
  • From: "Conor P. Cahill" <>
  • To: "Giuseppe Sarno" <>
  • Date: Thu, 10 Nov 2005 07:46:20 -0500
Send Email to
Send new message
Reply to this message

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").


By Date: Previous | Next Current Thread By Thread: Previous | Next

  Mail converted by the most-excellent MHonArc 2.6.10