RE: [security-services] suggested HoK URIs and namespace prefixes

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

> Not in grid deployments, no, that is far from true.

Yes, I know that. In virtually every other use case, it is true.

> So at least now I think I understand where some of your comments are
> coming from.  Comments such as: why couldn't a server bind a key to an
> assertion where the key was obtained previously, out of band?  I made
> some assumptions about this use case and suggested a patch to the
> profile to accommodate it (i.e., a timestamp), but at least one person
> (Conor) had a problem with that scenario.  So I'm not sure what to do
> about it.

FWIW, I still didn't read Conor's response as being about what you were
suggesting. He was talking about the time of confirmation and you were
talking about the time of initial key binding.

I accept your suggestion that it's a relevant data item (though not so much
to me), but I just don't know where it would go.

> Well, then I think the onus is on you to clarify these other use cases
> so that we can take them into consideration.  The dialogue thus far
> suggests this might be a useful exercise.

The basic use case is already profiled and specified in ID-WSF. Heck, I have
sample messages posted in the Internet2 wiki. By far the most useful HoK use
case is web services. Some of those cases could involve a client, but most
of them will be browser -> site -> service.

SSO with SAML from IdP to SP/WSC

SP/WSC to IdP with AuthnRequest for token for WSP

WSC to WSP with token (today we assume SOAP, but I think this can change)

The token contains the user in the subject, but the SP's key in the
SubjectConfirmation.

Various optimizations are possible and all of this is already defined to my
satisfaction (thus I don't think new profiles are needed for the SAML
protocol bits). What you want is a last step; to profile the actual
verification of HoK. That's fine, but it's orthogonal to the flows, and
should not need to know anything about who's requesting what or about whom.

What I further argue is that HoK in this context is about replacing PKI with
SAML. To that end, the goal should be to get to keys and compare them, and
avoid the brittle processing of certificates. Otherwise SAML doesn't need to
be there to begin with.

(Many of these points are distinct and not interdependent, but you did ask.)

-- Scott