[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Drafts for review: Kerberos & SAML profiles
Josh Howlett wrote on 2009-08-17: > My own interpretation (FWIW) of the WSS SAML token profile is that the > absence of text concerning the use of other confirmation methods did > not imply that other confirmation methods were not permitted. I'm sure that's true from a profile point of view, but I wouldn't be so sure from an implementation perspective. > It also seems to me that the use of a Kerberos-based HoK is also > compatible with the processing rules set out in sections 3.5.1.1 and > 2.5.1.2 of that specification, because this is left fairly open-ended. That I don't disagree with. What bothered me was more how you were representing the key than doing it at all, and using a different method gets around the problem of how to map a Kerberos identity into KeyInfo. > Is the absence of clarity in this respect likely to be problematic? Any implementation would have to have very specific knowledge of what you were doing here to have any chance of it working. It's not going to just work with existing code. So the question becomes how/where do you signal that difference to hook in the proper logic? And is it a good idea to reuse not only the method URI but also KeyInfo child elements to represent something completely different from typical usage? > I suppose we could define a new type ('KerberosData'?) for KeyInfo whose > semantics were less ambiguous, but I'm wary of unnecessary invention. I suppose a logical place to start might be with whether any existing practice exists around Kerberos + KeyInfo. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]