["Alistair Young" <alistair@xxxxxxxxxxxxx>]

Sorry to bring this up again but I was just beginning to understand it!

I'll try and use a real world example.

If an IdP issues an Assertion containing a Subject and Assertions about
that Subject to SPa and also issues, say, an Assertion that has an
AudienceRestriction for SPb. SPa holds the assertion destined for SPb.

While the user identified by the Subject is doing things on SPa, they do
something that causes SPa to communicate with SPb but not through the
browser. It's machine to machine. SPb wants an assertion about the user to
verify they have access to SPb. SPa gives the AudienceRestriction'd
assertion to SPb.

Now, I believe, this is where SubjectConfirmation comes in? SPb can use
this to work out the relationship between SPa and the Subject?

In the example in the SAML Core spec, the Subject and KeyInfo in
SubjectConfirmationData "belong" to the user.

My reading of this seems to be:

"Here's the subject and if you want to confirm them (whatever that means),
here's their key too"

but SubjectConfirmation is for SPb to identify the relationship between
SPa and the Subject:

"The <SubjectConfirmation> element provides the means for a relying party
[SPb] to verify the  correspondence of the subject of the assertion
[Scott@xxxxxxxxxxx] with the party with whom the relying party is
communicating [SPa]".

What is SPb meant to do with the key from the KeyInfo?

Am I really missing something?

thanks,

Alistair




-- 
Alistair Young
Senior Software Engineer
UHI@Sabhal Mòr Ostaig
Isle of Skye
Scotland

>
>
>
>
>
>
>
>
> 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
>
>
>
>
>
> ---------------------------------------------------------------------
> This publicly archived list supports open discussion on implementing the
> SAML OASIS Standard. To minimize spam in the
> archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Alternately, using email: list-[un]subscribe@xxxxxxxxxxxxxxxxxxxx
> List archives: http://lists.oasis-open.org/archives/saml-dev/
> Committee homepage: http://www.oasis-open.org/committees/security/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Join OASIS: http://www.oasis-open.org/join/
>
>