Re: [security-services] SAML2 Holder-of-Key Assertion Profile

[Frederick Hirsch <frederick.hirsch@nokia.com>]

Tom

Thanks for uploading the draft and for the comments.

I have a question regarding the XML Signature reference, which may  
result in a more general question.

Since SAML 2.0 has been standardized [1] the W3C has released a new  
edition of XML Signature, the Second Edition [2]. This is a  
maintenance release that incorporated errata, updated references, and  
added XML Canonicalization 1.1 as a required algorithm, addressing  
potential issues with xml:id and xml:ibase [3].

I note that the Holder-of-Key Assertion Profile draft references the  
original XML Signature recommendation. Should it reference the Second  
Edition? I would expect it to be compatible with both the first and  
second editions of XML SIgnature.

The more general issue is whether the SSTC should note on its web  
pages that SAML 2.0 should be compatible with XML Signature, Second  
Edition.

>  Indeed, this is what we have in [XMLSig] yet everyone agrees that  
> that's not adequate.

Do you mean is that the semantics and details regarding use of  
ds:KeyInfo are not fully described in XML Signature, or did I  
misinterpret what you are saying ?

> There's no way to extend [XMLSig] without introducing some process  
> (at least, I don't see how to do it).

Are you asking about the process of improving XML Signature in  
general, or about whether XML Signature schema has extension points?

Regarding the former, there is a new W3C XML Security Working Group  
actively working on a new version of XML Signature. I encourage  
bringing issues and requirements to that group [4], whose mailing  
list is public [5]. There are a few members of the SSTC active in  
that group. I  would like to understand any issues that you feel are  
important related to XML Signature and make sure that they are known  
to that Working Group.

Thanks

regards, Frederick

Frederick Hirsch
Nokia

[1] http://www.oasis-open.org/apps/org/workgroup/security/#samlv20

[2] http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/

[3] http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/explain

[4] http://www.w3.org/2008/xmlsec/

[5] http://lists.w3.org/Archives/Public/public-xmlsec/

On Aug 14, 2008, at 1:41 PM, ext Tom Scavo wrote:

> Okay, I changed the name of the "Holder-of-Key Subject Confirmation
> Profile" to "Holder-of-Key Assertion Profile" and uploaded to kavi as
> draft-02:
>
> http://wiki.oasis-open.org/security/SAMLHoKSubjectConfirmation
>
> I also removed all references to samlp: elements and trimmed the
> presentation as much as I could.  If you think the profile is
> confusing in some way, please let me know what you think is confusing
> and I'll fix it.  If you'd rather make the edits directly, please do
> so.
>
> All that said, I don't think calling this an "assertion profile" makes
> much difference.  I don't believe HoK subject confirmation can be
> profiled from a purely structural point of view.  Indeed, this is what
> we have in [XMLSig] yet everyone agrees that that's not adequate.
>
> There's no way to extend [XMLSig] without introducing some process (at
> least, I don't see how to do it).  There's a process that results in a
> HoK <saml:SubjectConfirmation> element in the first place.  Then
> there's another process that consumes such an element.  I don't see
> how you can profile HoK subject confirmation without describing those
> processes.
>
> Now if you claim that every profile should describe this process in
> its own words, I have to disagree.  If the presenter is the subject,
> and the subject presents a SAML request and an X.509 certificate to a
> SAML issuer, I can (and have) restricted the actions of the SAML
> issuer to a small set (4) of well-defined operations.  Moreover, if
> that subject turns around and presents a HoK assertion and an X.509
> certificate to a relying party, the RP knows exactly what it has to do
> to confirm the subject.
>
> The foregoing is a process, not a structure.  So this profile is not
> an assertion profile, it's a protocol-based profile.  The question is
> whether or not the process can be sufficiently generalized to be
> useful across a set (n > 1) of protocol-based profiles.  I claim it
> can.  This profile can be applied to Nate's HoK Web SSO Profile,
> Scott's SSOS Profile (which I haven't read), and my Self-AuthnRequest
> SSO Profile (which I haven't submitted yet).  That's n >= 3.
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>