|
|
saml-dev - RE: [saml-dev] Subject confirmation.
|
Message Thread:
Previous |
Next
|
- From: "Conor P. Cahill" <concahill@aol.com>
- To: "Giuseppe Sarno" <gsarno@nortel.com>
- Date: Thu, 10 Nov 2005 09:03:24 -0500
- Send Email to saml-dev@lists.oasis-open.org:
- 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:
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.
Conor
|
|