[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] suggested HoK URIs and namespace prefixes
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]