Re: [security-services] comments re sstc-saml-holder-of-key-browser-sso-draft-06

[Nate Klingenstein <ndk@internet2.edu>]

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.