[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: (REALLY) FINAL BALLOTS, GROUPS 6, 7, 8, 9
Attached are the (slightly) modified ballots for the issue groups 6, 7, 8, and 9. I was glad that we got a chance to debate these issues last week, and I tried to extract important comments from the discussion into the issues. As far as I could tell, there were not any comments on the resolutions themselves, or how the issues were stated, so mostly they are intact from the last ballot. Sadly, we -still- weren't able to reduce the number of privacy statements from 3 to 1, so the 3 stay in. Personally, I'm not that worried, since I'm pretty opposed to adding run-time privacy checks, and without those the privacy requirement is really too fuzzy to have in the doc. Please get your ballots in to Darren on Tuesday. Thanks, ~ESP
Group 6: Protocol Bindings
ISSUE:[UC-6-01:XMLProtocol] Should mention of a SOAP binding in the
use case and requirements document be changed to a say "an XML
protocol" (lower case, implying generic XML-based protocols)? Or "XML
Protocol", the specific W3 RPC-like protocol using XML
(http://www.w3.org/2000/xp/)?
Although SOAP is being reworked in favor of XP, the current state of
XML Protocol is unknown. Requiring a binding to that protocol by June
may not be feasible.
Per David Orchard,
"There is no such deliverable as XML Protocol specification. We don't
know when an XMLP 1.0 spec will ship. We can NEVER have forward
references in specifications. When XMLP ships, we can easily change
the requirements. [...] I definitely think we should mandate a SOAP
1.1 binding."
Possible Resolutions:
1. Change requirement for binding to SOAP to binding to XML Protocol.
2. Leave current binding to SOAP.
3. Remove mention of binding to either of these protocols.
Group 7: Enveloping Versus Enveloped
ISSUE:[UC-7-01:Enveloping] SAML data will be transferred with other
types of XML data not specific to authn and authz, such as financial
transaction data. What should the relationship of the documents be?
One possibility is requiring that SAML allow for enveloping
business-specific data within SAML. Such a requirement might state:
[CR-7-01:Enveloping] SAML messages and assertions should be able
to envelop conversation-specific XML data.
Note that this requirement is not in conflict with
[CR-7-02:Enveloped]. They are mutually compatible.
Possible Resolutions:
1. Add this proposed requirement.
2. Do not add this proposed requirement.
ISSUE:[UC-7-02:Enveloped] SAML data will be transferred with other
types of XML data not specific to authn and authz, such as financial
transaction data. What should the relationship of the documents be?
One possibility is requiring that SAML should be fit for being
enveloped in other XML documents.
[CR-7-02:Enveloped] SAML messages and assertions should be fit
to be enveloped in conversation-specific XML documents.
Note that this requirement is not in conflict with
[CR-7-01:Enveloping]. They are mutually compatible.
Possible Resolutions:
1. Add this proposed requirement.
2. Do not add this proposed requirement.
Group 8: Intermediaries
ISSUE:[UC-8-01:Intermediaries] The use case scenarios in the S2ML 0.8a
specification include one where an intermediary passes an S2ML message
from a source party to a destination party. What is the part of
intermediaries in an SAML conversation?
A requirement to enable passing SAML data through intermediaries could
be phrased as follows:
[CR-8-01:Intermediaries] SAML data structures (assertions and
messages) will be structured in a way that they can be passed from
an asserting party through one or more intermediaries to a relying
party. The validity of a message or assertion can be established
without requiring a direct connection between asserting and relying
party.
Possible Resolutions:
1. Add this requirement to the document.
2. Do not add this requirement to the document.
ISSUE:[UC-8-02:IntermediaryAdd] One question that has been raised is
whether intermediaries can make additions to SAML documents. It is
possible that intermediaries could add data to assertions, or add new
assertions that are bound to the original assertions.
If we wanted to support allowing intermediaries to add data to SAML
documents, the following use-case scenario could be added to the use
case and requirements document:
In this use case scenario, two parties -- a buyer and a seller --
perform a transaction using a B2B exchange as an intermediary. The
intermediary adds AuthN and AuthZ data to orders as they go through
the system, giving additional points for decisions made by the
parties.
[IntermediaryAdd.png]
Steps:
1. Buyer authenticates to Buyer Security System.
2. Buyer Security System provides a SAML AuthN assertion to Buyer,
containing data about the authentication event and authorization
attributes about the Buyer.
3. Seller authenticates to Seller Security System.
4. Seller Security System provides a SAML AuthN assertion to Seller,
containing data about the authentication event and authorization
attributes about the Seller.
5. Buyer requests authorization from Buyer Security System to submit
a given order.
6. Buyer Security System provides a SAML AuthZ Decision assertion to
Buyer, stating that Buyer is allowed to submit the order.
7. Buyer submits order to B2B Exchange, providing AuthN assertion and
AuthZ decision assertion.
8. B2B exchange adds AuthN assertion data, specifying that the
exchange authenticated the buyer (using the assertion).
9. B2B exchange adds AuthZ decision assertion data, stating that the
Buyer is permitted to use the exchange to make this order.
10. B2B exchange submits order to Seller.
11. Seller validates the order, using the assertions.
12. Seller requests authorization from Seller Security System to
fulfill a given order.
13. Seller Security System provides a SAML AuthZ Decision assertion to
Seller, stating that Seller is allowed to fulfill the order.
14. Seller submits intention to fulfill the order to the B2B exchange,
including AuthN assertions and AuthZ decision assertions.
15. B2B exchange adds AuthN data, specifying that it used the original
SAML AuthN assertion to authenticate the Seller.
15. B2B exchange add AuthZ decision data, specifying that the seller
is authorized to fulfill this order through the exchange.
16. B2B exchange sends the order fulfillment to the Buyer.
17. Buyer validates the order fulfillment based on AuthN assertion(s)
and AuthZ decision assertion(s).
Possible Resolutions:
1. Add this use-case scenario to the document.
2. Don't add this use-case scenario.
ISSUE:[UC-8-03:IntermediaryDelete] Another issue with intermediaries
is whether SAML must support allowing intermediaries to delete data
from SAML documents.
If so, the following use-case scenario could be added to the use case
document to illustrate.
Use Case Scenario X: Intermediary Delete
In this scenario, a buyer and a seller are using a B2B exchange to
perform a transaction. The B2B exchange acts as an intermediary
between the two parties. The exchange has an interest in not being
disintermediated by the parties, so it modifies submitted SAML data to
anonymize the buyer. This would prevent the seller from directly
contacting the buyer without using the exchange.
[IntermediaryDel.png]
Steps:
1. Buyer authenticates to Buyer Security System.
2. Buyer Security System provides a SAML AuthN assertion to Buyer,
containing data about the authentication event and authorization
attributes about the Buyer.
3. Buyer requests authorization from Buyer Security System to submit
a given order.
4. Buyer Security System provides a SAML AuthZ Decision assertion to
Buyer, stating that Buyer is allowed to submit the order.
5. Buyer submits order to B2B Exchange, providing AuthN assertion and
AuthZ decision assertion.
6. B2B exchange anonymizes the order by removing identifying
attributes from the SAML submitted by Buyer.
7. B2B exchange submits order to Seller.
Possible Resolutions:
1. Add this use-case scenario to the document.
2. Don't add this use-case scenario.
ISSUE:[UC-8-04:IntermediaryEdit] Similar to
[UC-8-03:IntermediaryDelete] is the issue of whether SAML must support
allowing intermediaries to edit or change SAML data as they pass it
between parties.
If so, the following use-case scenario could be added to the use case
document to illustrate.
Use Case Scenario X: Intermediary Edit
In this scenario, a buyer and a seller are using a B2B exchange to
perform a transaction. The B2B exchange acts as an intermediary
between the two parties. In this case, the buyer and seller use
different vocabularies for expressing security concepts and also
different vocabularies for domain concepts. The B2B exchange provides
a translation before passing on SAML documents.
[IntermediaryEdit.png]
Steps:
1. Buyer authenticates to Buyer Security System.
2. Buyer Security System provides a SAML AuthN assertion to Buyer,
containing data about the authentication event and authorization
attributes about the Buyer. One AuthZ attribute is that the Buyer
has a "role" of "purchase agent".
3. Buyer requests authorization from Buyer Security System to submit
a given order.
4. Buyer Security System provides a SAML AuthZ Decision assertion to
Buyer, stating that Buyer is allowed to submit the
order. Specifically, it states that Buyer has the "purchase"
privilege for the given order.
5. Buyer submits order to B2B Exchange, providing AuthN assertion and
AuthZ decision assertion.
6. Based on registered settings of the Seller, the B2B exchange knows
that Seller uses a different vocabulary than Buyer. For example,
Seller has only group-based AuthZ, not role-based. So it changes
the "role" attribute to "group".
Additionally, it knows that the Seller uses the term "buy" and not
"purchase" for the privilege of making an order, so it translates
that AuthZ information, too.
7. B2B exchange submits order to Seller.
Possible Resolutions:
1. Add this use-case scenario to the document.
2. Don't add this use-case scenario.
ISSUE:[UC-8-05:AtomicAssertion] One implicit assumption about SAML is
that assertions will be represented as XML elements with associated
digital signatures. Any additions, deletions or changes would make
the signature on the assertion invalid. This would make it difficult
for relying parties to determine the validity of the assertion itself,
especially if it is received through an intermediary.
Thus, the implementation of assertions as element + signature would
make [UC-8-02:IntermediaryAdd], [UC-8-03:IntermediaryDelete], and
[UC-8-04:IntermediaryEdit] difficult to specify, if the idea is to
actually modify the original assertions themselves. One possible
solution is that some kind of diff or change structure could be
added. Another possibility is that signatures on each individual
sub-element of the assertion could be required, so that if the
intermediary changes one sub-element the others remain valid. Neither
of these is a clean solution.
However, if there's no goal of changing the sub-elements of the
assertion, then it's possible to implement modifications. For example,
[UC-8-02:IntermediaryAdd] can be implemented without breaking apart
assertions. The B2B exchange could simply add its own assertions to
the order, as well as the assertions provided by the buyer.
Deletion and edition could be implemented by simply replacing the
assertions made by the buyer -- passing new AuthZ and AuthC assertions
made and signed by the B2B exchange. These would incorporate elements
from the assertions made by the Buyer Security System, but be signed
by the B2B exchange.
There is semantic value to who makes an assertion, though. If the B2B
exchange makes the assertion rather than the Buyer Security System,
there is a different level of validity for the Seller.
Since assertion as element + signature is a very natural
implementation, it may be good to express the indivisibility of the
assertion as part of a non-goal. One such non-goal could be:
[CR-8-05:AtomicAssertion] SAML does not need to specify a
mechanism for additions, deletions or modifications to be
made to assertions.
In addition, the use case scenarios should be edited to specifically
point out that additions, deletions or modifications make changes to
whole assertions, and not to parts of assertions.
Possible Resolutions:
1. Add this non-goal to the document, and change use case scenarios
to specify that intermediaries must treat assertions as atomic.
2. Don't add this non-goal.
Group 9: Privacy
ISSUE:[UC-9-01:RuntimePrivacy] Should protecting the privacy of the
user be part of the SAML conversation? In other words, should user
consent to exchange of data be given at run time, or at the time the
user establishes a relationship with a security system?
An example of runtime privacy configuration would be use case scenario
described in [UC-1-04:ARundgrenPush]. Because this scenario has been
rejected by the use cases and requirement group, it makes sense to
phrase this as a non-goal of SAML, rather than as a requirement.
[CR-9-01:RuntimePrivacy] SAML does not provide for subject
control of data flow (privacy) at run-time. The determination
of privacy policy is between the subject and security
authorities and should be determined out-of-band, for example,
in a privacy agreement.
Possible Resolutions:
1. Add this proposed non-goal.
2. Do not add this proposed non-goal.
ISSUE:[UC-9-02:PrivacyStatement] Important private data of end users
should be shared as needed between peers in an SAML conversation. In
addition, the user should have control over what data is
exchanged. How should the requirement be expressed in the use case and
requirements document?
One difficulty is that, if run-time privacy is out of scope per
UC-9-01:RuntimePrivacy, it's difficult to impose a privacy requirement
on eventual implementers. Especially considering that our requirements
doc is for the specification itself, and not for implementers. In
addition, specifications rarely proscribe guiding principles that
cannot be expressed in the specificied technology itself.
One statement suggested by Bob Morgan is as follows:
[CR-9-02-3-DisclosureMorgan] SAML should support policy-based
disclosure of subject security attributes, based on the identities of
parties involved in an authentication or authorization exchange.
Another, by Bob Blakley:
[CR-9-02-2-DisclosureBlakley] SAM should support *restriction of*
disclosure of subject security attributes, *based on a policy stated
by the subject*. *This policy might be* based on the identities of
parties involved in an authentication or authorization exchange.
A final one, by Prateek Mishra:
[CR-9-02-4-DisclosureMishra] An AP should only release credentials for
a subject to an RP if the subject has been informed about this
possibility and has assented. The exact mechanism and format for
interaction between an AP and a subject concerning such privacy issues
is outside the scope of the specification.
Comment by David Orchard:
"My concerns about all of the disclosure requirements, is that I cannot see
how any piece of software could be tested for conformance. In the case of
Blakely style, "SAM should support *restriction of* disclosure of subject
security attributes, *based on a policy stated by the subject*", how do I
write a conformance test that verifes:
o what are allowable and non-allowable restrictions?
o How do I test that an non-allowable restriction hasn't been made?
o How do I verify that a subject has stated a policy?
o How can a subject state a policy?"
Possible Resolutions:
1. Add [CR-9-02-3-DisclosureMorgan] as a requirement.
2. Add [CR-9-02-2-DisclosureBlakley] as a requirement.
3. Add [CR-9-02-4-DisclosureMishra] as a requirement.
4. Add none of these as requirements.
BALLOT
----------------------------------------------------------------------
All issue resolutions are mutually exclusive, so please choose one
option for each issue.
[UC-6-01:XMLProtocol]
1. Change requirement for binding to SOAP to binding to XML Protocol.
2. Leave current binding to SOAP.
3. Remove mention of binding to either of these protocols.
[UC-7-01:Enveloping]
1. Add proposed requirement [CR-7-01:Enveloping].
2. Do not add this proposed requirement.
[UC-7-02:Enveloped]
1. Add proposed requirement [CR-7-02:Enveloped].
2. Do not add this proposed requirement.
[UC-8-01:Intermediaries]
1. Add proposed requirement [CR-8-01:Intermediaries].
2. Do not add this requirement to the document.
[UC-8-02:IntermediaryAdd]
1. Add the given use-case scenario to the document.
2. Don't add this use-case scenario.
[UC-8-03:IntermediaryDelete]
1. Add the given use-case scenario to the document.
2. Don't add this use-case scenario.
[UC-8-04:IntermediaryEdit]
1. Add this use-case scenario to the document.
2. Don't add this use-case scenario.
[UC-8-05:AtomicAssertion]
1. Add the non-goal [CR-8-05:AtomicAssertion] to the document, and
change use case scenarios to specify that intermediaries must
treat assertions as atomic.
2. Don't add this non-goal.
[UC-9-01:RuntimePrivacy]
1. Add the proposed non-goal [CR-9-01:RuntimePrivacy].
2. Do not add this proposed non-goal.
[UC-9-02:PrivacyStatement]
1. Add [CR-9-02-3-DisclosureMorgan] as a requirement.
2. Add [CR-9-02-2-DisclosureBlakley] as a requirement.
3. Add [CR-9-02-4-DisclosureMishra] as a requirement.
4. Add none of these as requirements.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC
