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

["Scott Cantor" <cantor.2@osu.edu>]

> Yes, that's a very good point.  In fact, it exposes a flaw in the
> current profile: an issued <saml:SubjectConfirmation> element must
> include a timestamp.  Since the <saml:SubjectConfirmationData> element
> is extensible, this is fairly easy:

No, it's not. You'd be forced to define your own confirmation method,
because the existing method URI is already defined to use the constructs
built into SAML. That section in Profiles is not something you can ignore.
It applies to any use of that method. The attribute extensibility is for
other methods that might need them.

> In the same way that ForceAuthn affects AuthnInstant, a requester can
> force proof of possession by including an appropriate boolean value in
> a requested <saml:SubjectConfirmation> element:

That's more gray, I'd lean toward saying it's also questionable, but again
certainly not permissible with the existing HoK method.

> Unless there are objections, I'll include these requirements (and
> schema) in the next version of the HoK Assertion Profile.

I don't really even understand what you're saying is needed yet, so I'm not
even willing to take a position on it like Conor did. I don't thnk you mean
what Conor was describing, but I'm not sure. But it can't be done with the
existing method. That much is clear.

My inclination is to say that you're talking about something that belongs in
AuthnContext, though, since you were responding to something I wrote about
how authentication occurs. Why is this any different than AuthnInstant? And
before you ask "what if there is no AuthnStatement?", my response would be
"there should be if you care about this".

-- Scott