[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: draft-sstc-bindings-model-03.doc
>>>>> "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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC