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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: SAML2 Holder-of-Key Assertion Profile


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


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