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

[Nate Klingenstein <ndk@internet2.edu>]

Tom,

> - Draft-08 seems to be missing from the archive.  The link in the SAML
> wiki still works but the linked document is not exactly the same as
> the one I've reviewed (the two are off by a few lines).  I don't know
> what happened to that document.

This might be collateral damage resulting from my mistake in  
uploading a misversioned document.  I can try to repair the version  
history, since I've got all copies locally, if Kavi will let me.

> - Section 1.5 needs to be replaced with an inline revision history as
> suggested in this comment:
>
> http://lists.oasis-open.org/archives/security-services/200811/ 
> msg00030.html
>
> - A section entitled "TLS Usage" seems to be required.  The text in
> this new section should reference the steps in section 2.3 and
> emphasize where TLS is required and where it is optional.  Where it is
> optional (step 1), the possible uses of client TLS should be outlined.
>  (Possible uses of client TLS at step 1 include: 1) to construct a
> specific <saml:SubjectConfirmation> element, 2) to use the TLS session
> in lieu of a cookie-based session, and 3) to use information in the
> certificate for the purposes of IdP Discovery.)

I'm not going to be able to complete these two and still hand the  
document over to you in a timely fashion, so you're welcome to patch  
them in yourself.

> - Step 2 in section 2.3 needs to be rewritten.  (In particular, the
> last phrase in the last sentence is not clear.)  Also, I think the
> Identity Provider Discovery Profile should be mentioned (as long as
> you're mentioning other approaches to discovery).

Fixed; missed it with all the red ink leftover from change tracking.   
Reference added.

> - Bullets 3 and 8 in section 2.5.3 should be combined.  Bullets 9 and
> 10 can be combined.

There are a lot of other changes to this section in draft 10, but I  
think these changes still make sense in that context, so they should  
be there.

> - I'm still waiting for an opportunity to edit this document :-)

You're more than welcome to take a red pen directly to it after draft  
10.

All specific comments and wording changes fixed except...

> - [lines 329--330] I think a reference to [SAML2HoKAP] is  
> appropriate here.

I don't know if it's needed.  2.4 is mostly for a precise description  
of the flows, mirroring the (admittedly somewhat awkward) original  
Web SSO structure.  Since different confirmation methods don't alter  
the flows, and specific message processing is already spelled out in  
2.5, I'd rather omit it here.  This is made explicit in lines 314-315  
in draft 09, as well as the new paragraph you suggested.

> - [lines 343--345] The first part of this sentence should be moved to
> section 2.4.1 as a requirement for the SP.  Then rewrite the sentence
> as an "if-then" requirement.

I think this is in the off-by-one category resulting from my  
versioning mistake, and I can't guess what you're referring to.

> - [lines 360--361] I don't think there's any question that the SP will
> establish a security context.  Can you give a use case where a
> security context is not established?

The service provider might just process the assertion before handing  
the user agent off to an application with some information resulting  
from the assertion's processing, for example.  The user agent would  
then establish a security context and session with that app.  I don't  
know if this counts as creation of a security context with the SP or  
not.

> - [lines 361--362] Can you reword this sentence for clarity?

I don't see what's unclear about it.

> - [lines 376--380]  I think these requirements have been reworded in
> draft-09.  If not, this needs work.

I think this requirement has been removed, which should count as work.

> - [lines 435--437] This requirement makes no sense, I think it should
> be removed or at least reworded.

Not sure which you're referring to here again, but this section has  
already undergone extensive revision.  I'll give you a chance to  
check that out.

> - [lines 466--472] Is exclusivity required here?  Are there really two
> sets of requirements, one for endpoints to be used exclusively with
> this profile and one for shared endpoints?  I think this needs to be
> made clear.  (See comments re section 3 as well.)

I didn't want the wording to inadvertently force requirements on any  
shared endpoints.  I haven't changed the wording here because I think  
it's adequate, but you can.

> - [lines 490--491] This statement is true in general, not just for  
> this profile.

I see nothing wrong with reiteration of this point here.  It's  
important enough to merit that.

> - [lines 497--499] Here's the requirement I was looking for in section
> 2.6.  I think this requirement needs to be moved to section 2.6 for
> clarity and precision.

I like having it explicitly spelled out in the compatibility section,  
because separate endpoints should be used whether or not there's  
metadata involved.  Adding similar text to 2.6 would be fine by me.

> - [line 411] s/metadata or/metadata or a <saml:SubjectConfirmation>  
> element in/

Can't find this one.

Version 10 coming up shortly.
Nate.