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: RE: [security-services] SAML2 Holder-of-Key Assertion Profile


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

I don't think you have to say anything about the first half of that to say
something useful. For one thing, I think it's very difficult to do so. What
if I don't physically present a certificate or a key, but I login with a
password to an account that is known out of band to be mapped to a key? I
should still be able to issue a HoK assertion.

These are in some sense binding-level issues related to authentication,
which is very difficult to profile. Obviously you *can* nail it down more,
but I think doing that makes the profile somewhat less useful as a reusable
component.

Anyway, that's what I was trying to argue.

> The foregoing is a process, not a structure.  So this profile is not
> an assertion profile, it's a protocol-based profile.

Assertions are always presented in some protocol context, yes. But you can
(and I think have to some degree) describe the presentation in generic terms
in order to discuss only the confirmation structure and how it should be
used.

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

I think that's true in any case, my suggestions notwithstanding.

Separately, I would continue to argue that the profile would be better if it
forced a consistent key-based processing model. If I put a certificate into
the assertion, I want to be able to confirm that assertion with that key,
period. The fact that other syntaxes can also be used doesn't change the
value of that processing rule, because of the ubiquity and convenience of
certificates. I argue that there is no value in forcing certificate
equality, and advantages to not doing so. Consistency across the different
syntaxes, for one.

-- Scott




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