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

[Josh Howlett <josh.howlett@gmail.com>]

On 18 Aug 2009, at 16:22, Scott Cantor wrote:

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

Agreed.

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

Having now spent some time thinking over the WSS SAML Token Profile  
spec, I don't find that value particularly compelling. I find your  
argument of removing ambiguity (through the use of a distinct Subject  
Confirmation method) to be more compelling.

> I think we need input from
> the relevant experts on that, but I will try and scan the IMI  
> profile docs.

I think it would be useful to understand whether it is acceptable to  
use subject confirmation methods other than those that are mentioned  
in the  WSS SAML TP spec.

Interestingly, WRT the IMI spec (section 12) defines a set of  
identifier-types that are represented through an <Identity> WS- 
Addressing <EndpointReference> property. Two of these are Service  
Principal Name and User Principal name, and the semantics associated  
with those fit the Kerberos use-case.

I've only just skim-read the IMI profile, and so I'm not fully clear  
on what these are intended for. Oddly, each representation (DNS name,  
SPN, UPN, KeyInfo) has text that also describes how the endpoint can  
"prove its right to speak" as the identity. I'm puzzled by this but,  
for the Identity representations I care about, this text seems to be a  
suggestion rather than a stipulation.

best regards, josh.