Title: Message
Hi,
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:]
Sent: 10 November 2005
14:03
To: Sarno, Giuseppe [MOP:GM15:EXCH]
Cc:
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.
Conor
