OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [saml-dev] SAML Holder of Key Profile


[I'm assuming this is in reference to the SAML V2.0 Holder-of-Key
Assertion Profile (draft-08) and so I'm forwarding a copy of this
message to the SSTC public comment mailing list.]

On Wed, Jan 14, 2009 at 5:40 PM, Brett Beaumont
<brett.beaumont@fronde.com> wrote:
> 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?

Yes.

> 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.

Correct.

> Does this profile support that behaviour?

Implicitly, yes.  I'll make this explicit in draft-09.

> Or have I misunderstood the
> semantics for a NameID in the SubjectConfirmation element?

No, you have not misunderstood.  Thanks for pointing this out.

> 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.

Oops, this is wrong.  Thanks for pointing this out.

> 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.

Does not what?  No, 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.

> 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*.

> At this
> point, the RP doesn't know whether that cert is associated with the subject
> or not.

That's true, but that's not what I heard you say above.  The RP *does*
know that the cert is associated with the attesting entity, right?

> 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).

Yes, I agree.

> 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).

I don't disagree with your verbiage except that the RP must possess an
X.509 certificate known to be associated with the attesting entity.

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

It is subtle, and I make many such mistakes in the spec.  I will try
to clean that up in draft-09.  Thanks for pointing this out.

Tom


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]