Ballot Comments

[UC-6-01:XMLProtocol]

ESP: (2) I believe David's right on this, SOAP is what's there.

AZ: (2) SOAP and BEEP need to be added to binding list; it seems

that neither one of them is present currently.

JHodges (a) Rationale: From draft-sstc-use-strawman-03.html...

[R-Bindings] SAML should allow SAML messages to be transported by standard Internet protocols. SAML should define bindings of the message protocol to at least the following protocols:

standard commercial browsers

HTTP as a transport protocol

MIME as a packaging protocol

XML Protocol as a messaging protocol

ebXML as a messaging protocol

SOAP isn't presently in the list, so the ballot choices don't seem to make sense to me. I suggest we simply add SOAP (and BEEP) to the list (and keep XMLP) when producing draft-sstc-use-strawman-04. [R-Bindings] says "should" so I don't think we need to sweat this list a bunch right now -- we should list more here for now than might be formally accomplished *by this present SSTC incarnation* because (I claim) we should ultimately design SAML such that others may come along later and define bindings to the protocols we didn't get to or didn't even have on the list.

Hal (2): It seems we need to do SOAP now and consider other similiar protocols as they are defined.

[UC-7-01:Enveloping]

ESP: (1) We need to explicitly require this kind of functionality,

especially for session management, single-signon, etc.

Prateek: (2) Some care is needed on this issue. Are we proposing to build a general packaging infra-structure so SAML can "enclose" arbitrary XML payloads?? To me that seems to be far beyond the scope (and resources) of this group.

BobMorgan: (2) Comment on UC-7-01: There is a very slippery slope here, including recursive inclusion of SAML assertions, critical and non-critical included data, size expectations of SAML assertions, etc. Use of XML invites lack of clarity about functional layers; we should resist. We should standardize only the inclusion of elements that have clearly-defined semantics.

Jhodges (2) Rationale: I tend to agree with Eve that SAML constructs should be (or will

turn out to be) "standalone", but that said, I agree with Irving that it seems

we're getting the cart ahead of the horse here.

Dorchard (1) I would like a single place in the SAML message that allows for extension via a schema ANY construct, nothing more complicated than that.

[UC-7-02:Enveloped]

ESP: (1) This is crucial not only for B2B usage, but also for

making SAML useful for other XML standards.

IR: (Abstain)I feel that enveloping/enveloped formats will arise from particular

bindings and applications. We should let the requirement arise from a

specific use instead of arbitrarily asserting it. However, I don't feel

strongly enough about this to vote against.

Marlena: (1) Initially, I thought both enveloped/enveloping to

be "no-brainers", but then the dialog on the topic sowed doubt within me. I still have doubt but also I still think these both should be put in. I expect that if they are kept in, we will have more debate on them.

AZ: I vote for "1". Rationale here is that security assertions will need to be transported with business and application documents to

describe document originating parties identities and authenticated assertions. However, the issue David Orachard has raised w.r.t. enveloping vs enveloped requirements is an important one that we can possibly resolve further during the B2B use case ballot. Additionally, the enveloped issue is an important binding issue, e.g., SOAP, MIME, and ebXML.

BobMorgan: (2) Comment on UC-7-02: This is a mostly null requirement (what could we do to SAML assertions to make them un-fit?). A stronger statement of the same idea is that we should consider requirements of specific XML-based protocols/documents for included security assertions. This I believe we should not do at this time.

Jhodges (2) Rationale: I tend to agree with Eve that SAML constructs should be (or will

turn out to be) "standalone", but that said, I agree with Irving that it seems

we're getting the cart ahead of the horse here.

Hal (2) It is not clear to me that all requirements cannot be me with detached signatures. I may be wrong about this, however I think this is a design decision. Therefore I do not think we need these as requirements, even though the specifcations may include them.

DOrchard (2) After much thought, I think that it will probably be saml applications talking to each other, then the b2b applications afterwards. Enveloped leaves out the processing model and makes for difficult conformance testing.

[UC-8-01:Intermediaries]

ESP: (1) It's too limiting not to allow some form of intermediary.

IR: (1) This question really has two major parts: passing SAML through

intermediaries, and requiring that validity can be checked without

direct contact between AP and RP. The first is a clear yes, the

second I'm not so sure about.

BobMorgan (2): Comment on UC-8-01: The idea is generally valid but this requirement states it incorrectly. Multi-hop forwarding of assertions is needed in *some* scenarios; but not all assertions need this property. So this is a bindings issue: "There shall be bindings such that assertions can be verified when passed thru intermediaries".

Jhodges: (1) Rationale: I think we should put this in so we can continue to refine the notions therein (there's a fair amount of work to do here as DaveO notes). I tend to agree with Irving's thoughts on this item, as well as Prateek, DaveO, and Marlena thoughts.

Dorchard (1) Clearly something needs to be done with intermediaries. But I haven't seen any responses to my questions on intermediaries, so I haven't heard convincing use cases for add/delete/edit of assertions. So I will vote for intermediaries to keep in scope, as well as Adding as that seems a very explicable thing for an intermediary to do, and against each of the remaining particular instances. Prateek's argument convinces me to vote for add.

[UC-8-02:IntermediaryAdd]

ESP: (Voted 1) This seems useful, especially in combination w/ UC-8-05.

Nigel: (Voted 1) I am assuming that this will be rephrased to capture the idea that assertions are atomic. (Assuming [UC-8-05:AtomicAssertion] is voted in as a non-goal.) I think we need to allow cases where

assertions are added (but not elements of assertions).

IR: (1) The use case could be greatly simplified. We don't need a full-blown B2B design just to illustrate IntermediaryAdd.

Prateek: (1) We need to keep any "addition" real simple; assertions should be atomic but an intermediary can certainly add some new assertions. These new assertions may "depend upon" existing assertions.

Marlena: (1) I think "add" is fine in the sense of "adding on" but not in the sense of "adding in".

BobMorgan (2): Comment on UC-8-02: This is no doubt important, but I believe the

security relationships between the "B2B" players are not well-defined,

and the theoretical semantics of assertions-modifying-assertions are

tortuous. This is a good candidate for SAML version 2.

[UC-8-03:IntermediaryDelete]

ESP: (Voted 1)It's been discussed, it is a use case, we need to address it (but within the scope of UC-8-05).

Nigel: (Voted 2) As worded, it seems to me the intent is non-atomic assertions

BobMorgan (2): Comment on UC-8-03 and -04: Both of these violate what to me is a

fundamental aspect of an assertion, that it is integrity-protected

once issued. These requirements have to be met in some other way, by

issuing new assertions.

[UC-8-04:IntermediaryEdit]

ESP: (1)Again, it's something that's going to happen, we need to address it explicitly.

Nigel: Vote: 2 As worded, it seems to me the intent is non-atomic assertions.

Marlena: (2) "Deleting" and "editing" have the feel of "tampering" to me. If the intermediary is truly a trusted entity then it can rewrite the assertions and be believed. And rewriting is what it should do.

[UC-8-05:AtomicAssertion]

ESP: (1) An important clarification for all the intermediary use case

scenarios that, if not stated, could greatly increase the work of the

TC.

Marlena (1) Comment: I don't understand those folks who voted for Atomic Assertions" but who also voted to include delete/edit by intermediaries as a use-case. (I look forward to clarification.)

BobMorgan (2): Comment on UC-8-05: Since this point seems to be contentious, it

needs to be added as a positive statement: assertions are made by

asserting parties, can be securely associated with asserters by

receivers, can't be modified once issued, can't be passed along except

if protected by signature, etc. These are just basic security

principles.

Jhodges: I vote for "1", sorta. rationale: Nominally, I think we'll find that assertions will need to be "atomic". But I don't think we should express this using a "non-goal". And I'm concerned that we're straying far from "use cases & scenarios" and a ways into protocol design.

[UC-9-01:RuntimePrivacy]

ESP: (1) I believe that privacy and disclosure should be negotiated

between trust partners, and between user and service, out-of-band.

The overhead of making policy statements is too high.

[UC-9-02:PrivacyStatement]

ESP: (4) I think if we have [CR-9-01] added, we can dismiss the issue of

privacy.

IR: (4) I would support adding [CR-9-02-4-DisclosureMishra] as a 'best practice'

but not as a requirement.

Bob Morgan (4): Comment on UC-09: I agree that this level of requirement is not

consistent with the level of our other requirements. I hope we can

agree that SAML will be used in environments where privacy protection

is important; in that sense it is part of the "domain" in the same way

that other aspects of our domain model are. Scalability and other

"business requirements" as I have termed them are similar to this, and

unfortunately we don't currently have a place to capture these. So,

I'm content with this being referred to the security and privacy

considerations group for further oversight.

Jhodges: (1) I think we should keep this notion in-scope at a requirements level and the wording of "1" does it succinctly. Plus it is expressed as "should", not a "must". (we need to discuss the meanings of those words in a requirements context. I tend to think that having it as a "should" means that a design can still be considered to "meet" a should" requirement even if that notion isn't embodied in the design IF there are well-reasoned and well-expressed justifications for not meeting it.)

[UC-11-01:AuthzUseCase]

JeffH: (1) I think it is reasonable to keep it in at this point. I do however tend to agree with DaveO that tackling SSO first (in terms of actually designing and issuing a spec) is a higher priority. BUT, I think we'll want to do it with an eye towards this more broad functionality.

BobMorgan: (2) Comment on UC-11-01: It may be that it will be difficult to come to closure on interoperability of this function, but I think it's important to try, as at least the basic functionality is well-defined.

KellyEmo (2) David O. and I spoke at length about this yesterday. I am in support of this position as well, especially the point about focusing on one area that we can deliver successfully (Authn) all the way to being able to demonstrate compliance.

Dorchard (2) My rationale is that I think our spec has 2 halves and I'd rather finish them linearly, quickly and effectively. My plan is to do SSO first, thenAuthorization for SAML 1.1. These 2 features seem very orthogonal to me. This means that some vendor may implement AuthZ, and another implement Authn. So who is SAML compliant? I'd like to focus on one thing at a time without this "two-headed" spec we have.

security-use message