[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: ISSUE:[UC-2-08:ebXML]
Hi Maryann, On the concall of the use case and requirements working group this morning we reviewed the ballot for issue group 2, and a couple of questions arose related to ISSUE:[UC-2-08:ebXML]. Since this issue is essentially the ebXML use case you created, it seems that you would be the best person to clarify. Question 1: Steps 1-3 are specified in ebXML and not SAML, right? Question 2: Step 4 seems to add a specific requirement for SAML - that attribute authorities return attributes "based on the DN in the certificate used to sign the ebXML message". This seems to be the only requirement added for the ebXML use case. Are there others? If this is the only requirement and since the scenario is mostly describing an ebXML interaction, do we need to include the scenario as well, or just the requirement? We are voting on this issue this week - votes are due in by Friday. Any light you can shed on this issue in the meantime will be helpful - please send any clarification to the use case list. If you would like to suggest changes to the ballot itself, you can also contact me directly this afternoon at 415.652.2677. Any ballot changes will need to happen today. Here's the issue (from the current ballot): ISSUE:[UC-2-08:ebXML] Maryann Hondo proposed this use case scenario for inclusion in the use case document. (Note that an interaction diagram illustrating this use case still must be developed, to replace the current diagram. Also, the steps involved should be brought in line with other use case scenarios in the use case and requirements document.) Use Case Scenario X: ebXML This scenario shows the use of SAML for providing security services to an ebXML conversation. In addition, it gives an example of ebXML providing the necessary negotations to enable a SAML conversation. [ebXML.png] (attached here) Fig X. ebXML Steps: 1. Party A wishes to engage with Party B in a business transaction. To do this, Party A accesses information [stored in an ebXML Collaboration Party Profile (CPP)] about Party B's requirements for doing business. 2. Party A and Party B negotiate at ebXML Collaboration Party Agreement (CPA). Some of the information in a CPP or CPA might include: * Party B requires authorization attributes from AuthZServiceXYZ * Party B requires that Party A be authorized by XYZ in the BuyerQ role. Party A then must be able to determine: * How to get these authorization attributes. * where/how to insert these credentials in an ebXML message 3. Party A enrolls with AuthZServiceXYZ. Party A engages in ebXML business transactions and wants to restrict what entities are able to retrieve its authorization data. 4. Party B's Message Service Handler (MSH) has received a digitally-signed ebXML message from Party A and wishes to obtain authorization information about Party A * Authorization data must be retrievable based on the DN in the certificate used to sign the ebXML message. 5. AuthZServiceXYZ checks authentication of Party B to ensure B can read A's authorization data. It then returns the data to B. Potential Resolutions: 1. Add this use case scenario to the use case and requirements document. 2. Do not add this scenario. Regards, Darren
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC