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