RE: [saml-dev] SAML Holder of Key Profile

Hi Tom/Scott,

I see now where my confusion arose - much of what I was thinking about stems from the security protocol underneath the profile, rather than the HoK assertion itself. In my mind I hadn't separated the protocol from the profile :)

I was looking at the draft with specific interest in standards for how HoK tokens should work with web services. This is really the next level of detail down from the HoK profile, that binds the profile to a specific security protocol.

With respect to Proof of Possession (PoP), perhaps it just needs to be said that obtaining PoP of the cert is an RP responsibility - in order to comply with the definition of the SubjectConfirmationMethod. The means for obtaining that proof can be explicitly stated as beyond the scope of the profile. When standards bodies then bind the profile to a sepcific security protocol, they can define how PoP should occur within than protocol.

With respect to the term "attesting party", I notice that it isn't defined in saml-glossary-2.0-os.pdf, though I'm sure I have seen the term somewhere in the specifications. The "attesting party" is the entity presenting the SAML token. Under the Web-SSO profiles, the attesting party is technically the browser, even though we tend to consider the browser as actually being part of the subject. Under a web service model, the attesting party is the web service client.

Thanks again,

Brett

On Fri, Jan 16, 2009 at 8:35 AM, Scott Cantor <cantor.2@osu.edu> wrote:
> Tom Scavo wrote on 2009-01-15:
>> I disagree, the RP must possess an X.509
>> certificate known to be associated with the attesting entity. The RP
>> confirms the attesting entity before consuming the HoK assertion. It
>> does this by comparing the X.509 data in the certificate to the X.509
>> data bound to the HoK assertion.
>
> He means in advance of receiving the assertion. I think the confusion is
> that because you're writing a protocol-neutral set of processing rules,
> you're assuming various things would have taken place ahead of time.

Yes, I know. I'm realizing how hard it is to write a profile with no
protocol flow :-) Even your choice of words above ("in advance of"
and "ahead of time") hint of a flow embedded in time.

> Perhaps
> it's necessary to state those assumptions, not as processing rules like
> before but just as "given".

Yes, maybe that's a good way to think about it:

At the issuer:

1) The issuer possesses an X.509 certificate known to be associated
with the intended attesting entity (who may or may not be present)
2) The issuer issues a HoK assertion

At the relying party:

3) The relying party possesses an X.509 certificate known to be
associated with the target attesting entity (who may or may not be
present)
4) The relying party confirms the target attesting entity and
therefore concludes that the target attesting entity and intended
attesting entity are one and the same

The temporal requirements are:

- Step 1 precedes step 2.
- Steps 2 and 3 precede step 4

Strictly speaking, step 3 need not follow step 2 (though the numbering
suggests otherwise).

So now all I have to do is convert that into readable prose :-)

>>> When the attesting party presents the SAML Assertion to the RP, the
>>> attesting party proves possession of the attesting party's cert.
>>
>> This is where your argument breaks down. There is no notion of
>> "presenter" or "proof of possession" in this profile. Everything just
>> *is*.
>
> That's true within the scope of the profile, but once you embed the profile
> into an actual security protocol, both notions emerge as prerequisites
> simply because of the definition of subject confirmation. It only applies if
> both exist.

I agree, but exactly what are you proposing with respect to the HoK
Assertion Profile? Are you suggesting that we provide a typical usage
scenario to help ground the reader (or mislead the reader, as the case
may be).

Tom

saml-dev message