RE: [security-services] Drafts for review: Kerberos & SAML profiles

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

Josh Howlett wrote on 2009-08-18:
>  Perhaps I've missed something, but having stared at the WSS SAML TP's
> HoK Processing Rules for a while, I don't understand how you can expect
> interoperability between any two HoK implementations in any case...

My perception is the same, so I suppose that's better asked of somebody that
thinks existing WSS code isn't as terrible as I do. What I was trying to get
at was that if I was trying to support both traditional HoK and this, I'd
want a clear signal as to what I was supposed to do.

Unless we can identify a value proposition for reusing HoK, I don't see the
advantage. And the only value I can think of is if it causes problems with
WS-*, because of some presumed dependence on HoK as the method to use given
particular constructs in, say, WS-Trust or WS-SP. I think we need input from
the relevant experts on that, but I will try and scan the IMI profile docs.

> Hmm, I guess you could use a <wsse:SecurityTokenReference> in the
> <KeyInfo> that points to a Kerberos security token. But the WSS
> Kerberos Token Profile doesn't provide a concise way of naming a
> principal, just various value types that are Base64 encodings of
> Kerberos messages.

Right, I think that's a different use case.

> That would require that the SAML Issuer was in possession of (say) the
> service ticket at the time that the assertion was minted, which I
> think would be rather challenging to choreograph if not impossible.
> Merely naming a principal is significantly simpler for both the SAML
> Issuer and the RP to process.

I agree.

-- Scott