Re: draft-sstc-bindings-model-03.doc

[Evan Prodromou <evan@outlook.net>]

>>>>> "MP" == Mishra, Prateek <pmishra@netegrity.com> writes:

    MP> The bindings doc 0.3 is attached in word format. The
    MP> formatting has suffered some stress from integration of HTML,
    MP> .txt, and .doc sources but should still be readable.

Mea maxima culpa! B-) My .doc reader shows a number of <big> tags and
an HTML doctype at the top, but that might be because it's
non-Microsoft (OpenOffice).
 
    MP> I am looking for a high-end HTML editor: please send me a
    MP> recommendations if you have worked with one that does the job
    MP> for you.

The best I know of is DreamWeaver from Macromedia:

        http://www.macromedia.com/software/dreamweaver/

However, it's mostly targeted for Web design rather than for word
processing. You may want to check it out, though.
 
    MP> Lets discuss the doc. tomorrow at our 12PM con-call.

Here's a few comments based on my review of the document:

General:

* I think the layout and the scope of the document is very
  straightforward. I can clearly grasp the point of this effort and
  what is expected.

* The other thing that is clear is that we have a -lot- of work left
  to do. I believe we have the following required bindings (from the
  req'ts doc):

        * standard browsers profile (done)
        * HTTP protocol binding (done)
        * MIME profile (not done)
        * SOAP protocol binding (not done)
        * ebXML protocol binding (not done)

   Additionally, I think we have commits for the following bindings:

        * BEEP protocol binding (not done)

   Lastly, I think we talked on the last concall about these bindings:

        * SMTP protocol binding (not done)
        * Arbitrary XML profile (not done)

   Finally, we have one binding that I don't think was specified
   anywhere else, e.g.:

        * SOAP profile (done)

   It seems to be useful and well-done, though.

   Anyways, I guess I think it's important for us to discuss how many,
   if any, of the "not dones" will be "dones" by F2F #3, and who will
   do them. I believe I stepped forward for MIME, SMTP, and arbitrary
   XML (or else everyone else in line stepped back). I propose that
   making this schedule of duty should be an important part of our
   agenda tomorrow.

* Speaking of ebXML as a protocol binding... I'm no ebXML expert, but
  I'm not sure that it's a good candidate for a protocol
  binding. Maybe we need to have a special talk with our ebXML liaison
  (is that Maryann Hondo? I think so) and get a more accurate view of
  how SAML would bind to ebXML.

* Lastly, I think the document suffers a bit from a lack of
  parallelism between the different profiles and protocol
  bindings. I'm mostly to blame for this B-), but I wonder if it would
  be worthwhile to develop a short outline template for protocol
  binding sections and for profile sections ("Rationale", "Messages",
  "Errors", ...) so that it's easier for people adding protocol
  bindings and profiles to just "fill in the blanks."

Introduction:

* I think we had somewhat vague terms for what "bindings" were in the
  Requirements document. In [R-Bindings], the terms "communications
  protocol", "packaging protocol", and "messaging protocol" were
  used. I think the first and third would map to our "protocol
  binding" term, and the second would map to our "profile" term. We
  may want to recommend to the Focus group that the req'ts be changed
  to use the new(ish) terms.

* This is something of a niggling concern, but... "profile" does have
  a meaning in terms of security, or, rather, in terms of user
  databases or directories. That is, the record, or collection of
  attributes, that describe a user -- a "user profile." Specifically,
  we used the term "Profile" in AuthXML. I'm not sure if it's
  confusing in context, but it might be worth a disclaimer ("Don't
  confuse this with a user profile").

* I'm a little hesitant about the interop requirement. It's somewhat
  soft, but I think we all know what it means ("define enough that
  there's not _too_ much wiggle, and have principled extensions if
  any"). If it's expressed as a goal for our group, it's probably
  OK. As a goal for submitted protocol bindings or profiles, it might
  need to be more specific. I can't say I have any positive
  suggestions, though.

General Guidelines:

* Considering that we don't have any specific guidelines B-), it may
  be good to call these "guidelines" or even "rules."

* I'm not sure I understand 2). Does this mean, "the steps involved"?

* I think it might be good to specify the difference (if there is one)
  between 5) "integrity" and 4) "authentication."

Process:

* We should probably raise the issue of having a permanent
  registration service available to the rest of the TC and perhaps
  with Karl Best. It may make more sense to simply have future
  versions of the SAML specification include the best of ad hoc SAML
  protocol bindings and profiles as normative, or to publish "tech
  notes" for new protocol bindings and profiles.

* I think that providing an "arbitrary XML" profile may obviate a lot
  of the need for profile registration. There may be non-XML protocols
  that will be using SAML in the near future, but I'd put my bets on
  XML groups being the most voracious consumers of our standard.

HTTP Protocol Binding:

* I think this needs some work to fit the guidelines. In particular,
  3) whether intermediaries are allowed (not sure how to call that one)
  and 4) authentication.

* Despite laying out a vocabulary, I didn't follow it, and sometimes
  used "request" when I meant "HTTP request." This probably needs some
  work.

Browser Profile:

* I liked this a lot, but I'm concerned about interop. Would it be too
  onerous to state that the "Web Browser Basic Profile" is the _only_
  allowed profile? Or do we expect improvements? Are there problems
  with it?

  Considering that AFAIK the browser profile is crucial to SSO
  (correct me if I'm wrong here), and that SSO is probably one of our
  highest success metrics for SAML (again, correct me), I'd say that
  it'd be quite appropriate to make this profile very, very, very
  tight, with the bare minimum of wiggle room.

* I'd propose that it may be useful, and in fact expedient, to add two
  extra data fields to the Web Browser Basic Profile SAML artifact:

        Time - time the AP sent the user to the RP (to prevent replay)
        IP Address - IP address used by the user (again)

  I think there's low overhead here, and it allows for some tightening
  of the system.

* Also, rather than a random byte string, could AssertionID be the
  actual ID stored in the assertion? Per the Assertions spec?

SOAP:

* I have a bit of trepidation about SOAP, frankly. I'm not using it
  much yet, and from what I understand there are a lot of
  semi-interoperable standards out there that don't quite fit up. We
  might want to give a definite, unequivocal version that we bind
  to. I believe we have a SOAP liaison, too, correct?

* As mentioned before, I think we still need to make a protocol
  binding for SOAP. Namely, using SOAP for SAML messages, rather than
  using SAML assertions for SOAP.

* As for "scoping" (last paragraph): I was thinking that maybe we have
  a third mechanism, that is, including the fingerprint of the
  principal's public key, rather than the entire key. I'm not sure if
  this is appropriate, though.

* I think we have a number of public-key encryption experts in the
  SAML TC -- this might be a valuable issue to bring up to the entire
  TC. I am admittedly weak in this field.

Well, almost 200 lines after stating that I had a "few" comments, I
come to the end. I'll probably have more by tomorrow, but there's a
start, eh? B-)

~ESP

-- 
Evan Prodromou <evan@outlook.net>
Applications Lead
Outlook Technologies, Inc.