Subject: Re: [security-services] comments re sstc-saml-holder-of-key-browser-sso-draft-06
Tom, > - I don't believe the solution proposed in section 2.6 is general > enough. Some other profile will likewise have to define a "Protocol" > attribute since basically this is a bug in SAML metadata. Should the > "patch" be defined once and for all? I'd like this, but we have a rapidly growing number of use cases for this profile and I'd like to get this through apace. I'd sooner keep this one-off going unless there is a draft proposed that I can rely on, and modify it later through errata if necessary. > [lines 145--146] I understand the intention of this sentence, but > elsewhere in the document you suggest that the certificate might be > used as an authentication token and/or IdP Discovery, so this sentence > appears to conflict with later suggestions. I think it's pretty clear that this sentence only regards assertion processing, and I want to keep the introduction as short and clear as possible. > [lines 254--263] The sentence on lines 254--255 conflicts with the > paragraph on lines 259--263. The X.509 certificate can not be used as > an authentication token without a "traditional PKI." Technically, sure it could. ;D But I think that this reads pretty clearly the way it is now. Could you suggest some specific changes to the text? > [lines 368--370] The phrase "MUST honor them if it can" is a > meaningless requirement. Does the IdP return an error if it can't > honor these aspects the request? Good point. I've removed the "if it can". If it can't honor the endpoints and bindings in the request, that's an error condition. > [section 220.127.116.11] This section is redundant (see lines 375--377). Good catch, but I think I prefer it there, so I've axed 375-377. > [lines 501--502] Is it necessary that these endpoints be used > "exclusively" with this profile? I don't see why this should be so. It was just to limit confusion. The endpoint could probably be used for a variety of profiles, in which case the URN should probably not include browser SSO. However, it makes sense as a requirement at least until there's a generalized version of the hok:Protocol attribute, and probably after that as well. I've left it in for now. > [line 509] Why is this attribute called "Protocol"? Isn't "Binding" a > more appropriate name for this attribute? After all, it's value is a > binding URI. I thought having both Binding and hok:Binding would be seriously confusing, particularly to people who don't understand XML well. While protocol isn't a perfect fit, I think it's a small evil. I explicitly used the phrase "protocol binding" in the explanatory text in hopes that'd help. > [lines 542--547] This isn't true (or at least it's misleading). It > depends on whether or not the X.509 certificate is used as an > authentication token. If it is, then what you say is true. If it's > not, then most of these "limitations" can be avoided. I'll soften it to a "may be limitations", but I think the rest of it is a pretty fair assessment. I'd like to explicitly be sure people are aware of deployment choice implications here. I included nothing about a <samlp:AuthnRequest> containing a <saml:SubjectConfirmation> in the interest of saving time. We don't really have a document to place the appropriate text in, as the assertion profile is about assertions and mine is a specific profile. I wouldn't mind referencing one if and when it exists. Whewf. Better with each revision, but it's mortifying how much you always manage to find. I've uploaded a new revision, which is the eleventh hour even by my standards, and won't be able to make today's call due to travel. Anything else I didn't comment on, I accepted as a change. Take care, Nate.