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