SAML Holder of Key Profile

["Brett Beaumont" <brett.beaumont@fronde.com>]

Hi,

 

I have a couple of questions about the Holder of Key profile.

 

1. Can I still have a NameID element in the SubjectConfirmation element?

 

I understand from SAML Core I can put a NameID under the SubjectConfirmtation when the attesting party is different from the subject. This could be the case in web services, where the web service consumer is the attesting party wanting to assert its permission to act on behalf of the subject of the assertion.

 

Does this profile support that behaviour? Or have I misunderstood the semantics for a NameID in the SubjectConfirmation element?

 

2. Lines 190 - 191: It is assumed that both the SAML issuer and the relying party each possess an X.509 certificate that is known to be associated with the subject of the assertion.

 

My understanding was that the SAML Issuer must possess an X.509 cert known to be associated with the subject (or intended attesting party), but the RP does not.

 

When the attesting party presents the SAML Assertion to the RP, the attesting party proves possession of the attesting party's cert. At this point, the RP doesn't know whether that cert is associated with the subject or not. The RP then compares the attesting party's cert with the cert inside the assertion to see if they are the same. If they are, then all is good. If they are not, then the RP is not talking to the anticipated subject (or attesting party).

 

I want to be check that I understand correctly that the RP does NOT need to know in advance what cert the subject (or attesting party) *SHOULD* be using. I understand that knowledge to be embedded in the assertion itself. Instead, the RP needs to know what cert the attesting party *IS* using. It then compares the two certs to check whether the actual attesting party (cert shown to the RP) is the same as the intended asserting party (certificate asserted in the SAML assertion).

 

The difference is fairly subtle, but I want to be clear I understand it properly.

 

 

Thanks,

 

Brett Beaumont