OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [saml-dev] Subject confirmation.

Title: Message
it will probably take sometime to digest this, but you gave me some good thoughts and material to go through.
It looks like this is an important feature in SAML.
Many thanks in the mean time for you help.
-----Original Message-----
From: Conor P. Cahill [mailto:concahill@aol.com]
Sent: 10 November 2005 14:03
To: Sarno, Giuseppe [MOP:GM15:EXCH]
Cc: saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] Subject confirmation.

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: http://www.oasis-open.org/committees/download.php/15256/Web%20Services%20Security%20SAML%20Token%20Profile-11.pdf)
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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]