On Thu, Mar 13, 2008 at 3:36 AM, Nate Klingenstein <> 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
