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 09:03:24 -0500
Send Email to
Send new message
Reply to this message

Giuseppe Sarno wrote on 11/10/2005, 8:35 AM:

AP could include a HolderKey confirmation method + key.
This means that the Party A should prove somehow that he holds that key (by enc/decryp a message or the NameID itself or by any other mean) with the RP.
(this where it gets a little bit confuse, how the PartyA proves he holds the key)
I guess though this must be out of the scope of SAML. (if you have an example it would be helpful)
The best example would be the proposed SAML token profile v1.1 for WSS (available at:
For the Subject in the Confirmation, sorry I didn't mean subject but BaseID/NameID/Enc...ID instead. They are present at the Subject level as well as the SubjectConfirmation level.
In the Subject Confirmation, this is the identity of the *entity* that is able to do the confirmation, if available.  In your example, Party A would be the entity sending the message to RPA and would be identified with an ID in the subject confirmation.  Of course, if Party A was a browser, it doesn't have a unique identity and so  there would be no identity there in such a case.

But looking at the schema I assume that those will be included in the confirmation only if they are not present at the  Subject level.
That's not the case.  They ID's identify different parties (the Subject vs the entity that can meet the confirmation requirements).

In our model, the SubjectConfirmation IDs (SCIDs) would not be present during browser based SSO or with tokens issued to intelligent clients (active participants in the SSO process),  when either client communicates with a relying party.  But later, when that relying part turns around and invokes another service that is part of the same "session" with the Subject, the token that they get to invoke the subsequent service will include the identiy of the relying party in the SCID).  So we will have tokens with or without SCIDs depending upon the context.


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

  Mail converted by the most-excellent MHonArc 2.6.10