[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Next round of ballots
Evan and I are working on the ballots for issue groups 6, 7, and 8, got ambitious and are attempting to do group 9 as well. We are not sure how to handle issue 9-02, though, and would appreciate some input here. There have been a couple of proposals for the wording of a requirement related to disclosure of authorization attributes - it would be great if we could work out a final proposal for the ballot. Otherwise we'll vote on the two. They don't seem to be that different though. Here's the issue... ISSUE:[UC-9-02:PrivacyStatement] Important private data of end users should be shared as needed between peers in an SAML conversation and protected entirely from hostile 3rd parties. 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? Should a use case scenario illustrating privacy protection be provided? Here are the proposed resolutions: [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. [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. I see two times a user may be asked to decide whether it's okay to share thier info - provisioning and runtime. The runtime-related requirement is covered by ISSUE:[UC-9-01:RuntimePrivacy]. The other is being discussed here, I believe, where a user establishes the policy for sharing thier info at the time that they create their account. Personally, I feel that if we specify that a subject define a policy for sharing his information at provisioning time then it will need to be a requirement that is specified as 'optionally implemented', because there will be many cases where this is not required behavior. In other words, we could specify the format of these policies and how to apply them, but implementations would not have to support it to be compliant with SAML. In addition, I feel that this is the type of thing that could be handled outside the scope of SAML, much like XACML. Regards, Darren Darren Platt Principal Technical Evangelist Securant Technologies 345 California St., 23rd Floor San Francisco, CA 94104 tel - (415) 263-4976 fax - (415) 764-4949 http://www.securant.com/ -----------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC