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

["Tom Scavo" <trscavo@gmail.com>]

On Thu, Mar 13, 2008 at 3:36 AM, Nate Klingenstein <ndk@internet2.edu> wrote:
>
>  > (By the way, why are the latter set in monospace font?)
>
>  Keywords.  It's to set them apart as being specified fields, even if
>  from another standard.  Is that inappropriate?

IMO, not in this case, no.  A monospace font usually denotes code of
some type (XML, e.g.) but here it's used to emphasize fields in an
X.509 certificate, that is, ASN.1, the furthest thing from a textual
representation!

>  > - Is this profile meant to be a refinement of the Web Browser SSO
>  > Profile in [SAML2Prof] or is it meant to be a complete replacement?
>
>  Unfortunately, it can't be a pure derivation/refinement because the
>  Web Browser SSO profile mandates the use of bearer SubjectConfirmation
>  with a normative MUST.  What do you believe it needs to include that
>  isn't already if it seeks to be an alternative rather than a refinement?

Okay, I'll review the next version with this in mind.  (I was thinking
of this as a refinement, but maybe you're right.)

>  > - Wherever encryption is mentioned, one gets the impression it is
>  > required or assumed.  But encryption is not required as far as I know,
>  > so any subsequent conclusions or requirements seem to be based on a
>  > false assumption.  So what are the encryption requirements of this
>  > profile?  I suspect there are none, so I suggest you go back and
>  > rewrite any paragraph that has the word "encryption" in it.
>
>  Every reference to encryption that I can find is explanatory or
>  describes options faced by a deployer and isn't normative.  Many of
>  these would be migrated into a consolidated security/privacy
>  considerations section.

Yes, thanks, moving encryption into the "Security" section will take
care of this problem.  What remains will have to stand on its own.

>  > - In section 1.3 (Conformance), try to specify what sections are
>  > required for a conforming SP.  Similarly, specify what sections are
>  > required for a conforming IdP.  I don't think you want to leave this
>  > up to the reader.
>
>  There's no harm in tabulating them, really, but isn't it somewhat self-
>  evident?

See section 7 of this template:

http://docs.oasis-open.org/templates/OASISSpecificationTemplateGuidelinesV4.0.html

We're still learning what's required, but I have a sinking feeling
that what you have now will not pass muster.

>  > - The body of section 2 (sections 2.4 and 2.5) is disorganized.  For
>  > one thing, there is more than one incorrect cross-reference, which is
>  > annoying.  Perhaps the next version of the document can reorganize the
>  > subsections in section 2.  It would be helpful if there were a
>  > one-to-one mapping between the subsections of sections 2.4 and 2.5,
>  > respectively.  In the very least, cross-references should be used
>  > freely, and they should be correct.
>
>  With the exception of incorrect cross-references, my (totally
>  mislabeled) intent was to split the sections into the protocols/
>  bindings and the assertion/messages they transport.  This is made more
>  awkward by the fact that the authentication request is protocol only.
>  For some of the steps in 2.4, there is no real corresponding text to
>  put in 2.5: it's all binding, and sometimes not SAML.
>
>  What would you suggest?  Collapse them into one section, try to draw
>  this distinction more sharply, or use another separator entirely?

I don't have a hard and fast suggestion right now.  Maybe if you fix
the cross-references that are there, and add a couple more, it will
fall in place.  More than once when I was reading those subsections, I
was expecting a requirement that turned out to be somewhere else.

Another thing I noticed, you don't say anything about the requirements
of the user agent.  It's almost like the user agent is invisible and
doing only what it's told.  That's not the way I think about it.  What
if I wanted to implement a user agent that conformed to this profile?
What would it have to do?

>  > - I suggest you break out the authentication request/response sequence
>  > into a separate profile.  This will, first of all, simplify an already
>  > complicated section 2. Secondly, it's likely someone will want to
>  > implement the authentication exchange outside of the normal browser
>  > profile.  Indeed, the HTTP-based authentication request/response that
>  > you've profiled here is much easier to implement than the SOAP-based
>  > attribute self-query I profiled recently!  So having those
>  > requirements in a separate section would be very helpful.
>
>  As mentioned above, I hoped to draw this same line between 2.4 and
>  2.5.  I can understand (and am pleased by) the desire to recycle the
>  concepts in the profile.  However, I don't think splitting this into
>  two separate profiles is the right way to do that.  I believe the
>  coupling between the application-layer assertion and the transport-
>  layer TLS protocol makes this profile interesting, so pulling them
>  apart seems like it'd leave two somewhat disjointed halves that don't
>  say much.

I disagree (but I don't think I did a good job of making my point).
Suppose a user is only interested in obtaining a holder-of-key
authentication assertion from an IdP.  (Forget about what happens to
the resulting assertion.)  So now I go about implementing an HTTP user
agent that formulates an AuthnRequest and issues a request.  What are
the requirements associated with this request/response?

I didn't make up this scenario, since we want to do just that!
Moreover, you yourself proclaim that an IdP-first flow is allowed, so
all I'm suggesting is that you break that out and do it first.  I'll
bet the entire profile becomes more clear as a result.

Okay, that's enough for now :-)  Keep up the good work, Nate!

Tom