> Well, I thought you were talking about binding X.509 data to a
> SubjectConfirmation element based on a proof of possession in the
> past.
Possibly/probably. I wasn't really trying to be specific.
> The act of authentication and the proof of possession are separate
> processes in general. Not unlike basing an authentication on an
> existing security context, I thought you were suggesting that a
> holder-of-key SubjectConfirmation element might be based on a previous
> proof of possession.
Yes, that's true, but it doesn't change my impression. This information
doesn't belong in the SubjectConfirmation itself. It's informational, but it
doesn't constrain or otherwise describe how confirmation should be done. It
strikes me as something that fits into the gray areas of AuthnContext, which
tells me it's probably something that only a few people will care about,
though likely the vocal ones.
That said, I reread the Profiles text and I think I'll retract my statement;
as long as the extension is optional, it fits into the existing text, which
says what you MUST include (KeyInfoConfirmationDataType) but not what you
MAY add to that, like with any extension.
> Maybe I was reading too much into your remarks. If so, that's fine,
> since the use case doesn't seem to be awfully compelling anyway.
The use case was merely to demonstrate that I don't believe your profile can
fully describe the request step, and so shouldn't attempt to say anything
about it.
> Yes, there is an AuthnStatement but not in this "assertion profile."
> It is specified in the next profile that begins to flesh out the
> protocol exchange that results in a HoK assertion.
Yes, I understand.
-- Scott
