[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] SAML2 Holder-of-Key Assertion Profile
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]