Seeking clarity on the SubjectConfirmation element

Title: RE: [saml-dev] HTTP error response code

Hi Folks,

 

I am seeking your confirmation that I 
understand the SubjectConfirmation element.  Below I have written 
up my understanding of it.  

Understanding the SubjectConfirmation Element
Motivation

First I provide the motivation for why an 
element such as SubjectConfirmation is needed.  Consider this 
scenario:

 

A Bad Guy steals (intercepts) an 
assertion that is sent by an Identity Provider (IdP).  The Bad Guy 
presents himself and the stolen assertion to a Service Provider (SP).  How 
will the SP determine that the presenter is not the real subject of the 
assertion?  Answer: before the IdP sends out the assertion, he embeds 
a SubjectConfirmation element into the assertion.  The SubjectConfirmation 
element contains a digital version of a lock.  The SP asks the presenter 
(the Bad Guy) for the key to the lock.  Since the Bad Guy doesn't have the 
key the SP knows that there is something fishy with the presenter.

 

So, the motivation for the 
SubjectConfirmation element is to provide a way for the SP to determine if the 
presenter is the real subject of the assertion.

Recap

The SubjectConfirmation element contains 
information about how the presenter of the assertion must confirm that he is the 
subject identified in the assertion.   For example, the 
SubjectConfirmation element may contain a ds:KeyInfo element, which means that 
the presenter can confirm he is the subject of the assertion by giving a secret 
key.

Questions

Question #1: do I correctly understand the 
purpose of the SubjectConfirmation element?

 

Question #2: does it make sense to use the 
SubjectConfirmation element in a WebBrowserSSO profile?  I think that it 
doesn't make sense because the whole point of this profile is to avoid making 
the presenter reauthenticate, and the presence of the SubjectConfirmation 
element implies that the SP should reauthenticate the presenter, correct?  
On the other hand, isn't it risky for the SP to not reauthenticate?  
Suppose that the presenter has a stolen assertion as I describe above; the SP 
would be taking a big risk by not reauthenticating the presenter, 
correct?

 

/Roger