This wiki has undergone a migration to Confluence found Here
Difference between revisions of "March 13, 2018 PSAF Call"
Jump to navigation
Jump to search
Line 60: | Line 60: | ||
*Second is the overarching Trust Model with the three types of Authority Domains: Jurisdictional, Organizational, and subject of care. Removed the Venn Diagram from the Federated Domain because the trust contract is no longer considered an integration of policies, but a bridging between two domains where the disclosing domain has the final say on whether the policies in the trust proposal from the requesting domain are acceptable, and executes the contract. | *Second is the overarching Trust Model with the three types of Authority Domains: Jurisdictional, Organizational, and subject of care. Removed the Venn Diagram from the Federated Domain because the trust contract is no longer considered an integration of policies, but a bridging between two domains where the disclosing domain has the final say on whether the policies in the trust proposal from the requesting domain are acceptable, and executes the contract. | ||
*Third sequence diagram "Establish Trust Contract Model" illustrates the flow of the trust message between the requesting and disclosing domains. A third Trust Framework actor was added, which controls the policy resolution service, external policy management service, and federated trust contract. | *Third sequence diagram "Establish Trust Contract Model" illustrates the flow of the trust message between the requesting and disclosing domains. A third Trust Framework actor was added, which controls the policy resolution service, external policy management service, and federated trust contract. | ||
− | *Policy Bridging Boundary View Use Cases illustrates the relationships among Access Control Services and Trust Management Services. This is the use case illustrated by sequence diagram, so is not a workflow. It shows that Domain A has capability to send trust proposal to Domain B. B has capability to receive the proposal and to get policies from the Policy Administration Point. B has the capability to send any run time policies and the policies in A's trust proposal to a Policy Resolution Service. Policy Resolution Services has capability to get saved trust policies from an External Policy Management Service. | + | *Policy Bridging Boundary View Use Cases illustrates the relationships among Access Control Services and Trust Management Services. This is the use case illustrated by sequence diagram, so is not a workflow. It shows that Domain A has capability to send trust proposal to Domain B. |
+ | *Domain B has capability to receive the proposal and to get policies from the Policy Administration Point. B has the capability to send any run time policies and the policies in A's trust proposal to a Policy Resolution Service. Policy Resolution Services has capability to get saved trust policies from an External Policy Management Service. | ||
+ | *Policy Resolution Service has the capability of bridging input policies to (1) execute a trust contract, which is equivalent to Domain's trust proposal by counter signing that proposal; or (2) generate an alternative signed trust proposal, which Domain B's ACS sends to Domain A's ACS. | ||
+ | *Domain A's Policy Resolution Service evaluates against it's PAP and saved policies in External Policy Management Service. If acceptable, Domain A's Policy Resolution Service may sign this proposal to execute a trust contract, which is submitted to Domain B. In the alternative, Domain A's Policy Resolution Service may generate a counter trust proposal, which is sent to Domain B's ACS to continue the process until either party declines to continue or a trust contract is established. |
Revision as of 17:42, 15 March 2018
Attendees
. | Member Name | . | Member Name | . | Member Name | . | Member Name | |||
---|---|---|---|---|---|---|---|---|---|---|
. | John Moehrke Security Co-chair | x | Kathleen Connor Security Co-chair | . | Alexander Mense Security Co-chair | . | Trish Williams Security Co-chair | |||
x | Christopher Shawn] Security Co-chair | x | Suzanne Gonzales-Webb | x | Mike Davis | . | David Staggs | |||
. | Mohammed Jafari | x | Beth Pumo | . | Ioana Singureanu | . | Rob Horn | |||
x | Diana Proud-Madruga | x | Francsico Jauregui | . | Joe Lamy | . | Galen Mulrooney | |||
. | Paul Knapp | . | Grahame Grieve | . | Johnathan Coleman | . | Aaron Seib | |||
. | Ken Salyards | x | Jim Kretz | . | Gary Dickinson | x | Dave Silver | |||
. | Oliver Lawless | . | [1] | . | David Tao | . | Greg Linden |
Agenda
- (3 min) Roll Call, Agenda Approval
- (5 min) Review and Approval of the March 6th Minutes
- (50 min) TF4FA Ballot Work Session - Mike Davis and Chris Shawn
Minutes
- Chris Chaired
- Agenda and Minutes were reviewed. Kathleen moved, Mike seconded. 7-0-0.
- Mike walked through recent changes to Trust Framework for Federated Authorization. We've restructured the TF4FA from one volume with 2 Chapters into two separate volumes. Also working on a third volume for Audit, Provenance, and Blockchain.
- Ballot document will follow PASS ACS format with a business, information, computational and engineering perspectives. In conformance with RM-ODP, business perspective is converted to enterprise viewpoint. Computational view is deemed out of scope.
- Initial Policy Diagram model is a high level view of the 4 key classes from ISO TS 22600-2:2006: Policy class specialized into Basic, Meta, and Composite policy. TF4FA will focus on Basic policy class. Meta and Composite
- Second is the overarching Trust Model with the three types of Authority Domains: Jurisdictional, Organizational, and subject of care. Removed the Venn Diagram from the Federated Domain because the trust contract is no longer considered an integration of policies, but a bridging between two domains where the disclosing domain has the final say on whether the policies in the trust proposal from the requesting domain are acceptable, and executes the contract.
- Third sequence diagram "Establish Trust Contract Model" illustrates the flow of the trust message between the requesting and disclosing domains. A third Trust Framework actor was added, which controls the policy resolution service, external policy management service, and federated trust contract.
- Policy Bridging Boundary View Use Cases illustrates the relationships among Access Control Services and Trust Management Services. This is the use case illustrated by sequence diagram, so is not a workflow. It shows that Domain A has capability to send trust proposal to Domain B.
- Domain B has capability to receive the proposal and to get policies from the Policy Administration Point. B has the capability to send any run time policies and the policies in A's trust proposal to a Policy Resolution Service. Policy Resolution Services has capability to get saved trust policies from an External Policy Management Service.
- Policy Resolution Service has the capability of bridging input policies to (1) execute a trust contract, which is equivalent to Domain's trust proposal by counter signing that proposal; or (2) generate an alternative signed trust proposal, which Domain B's ACS sends to Domain A's ACS.
- Domain A's Policy Resolution Service evaluates against it's PAP and saved policies in External Policy Management Service. If acceptable, Domain A's Policy Resolution Service may sign this proposal to execute a trust contract, which is submitted to Domain B. In the alternative, Domain A's Policy Resolution Service may generate a counter trust proposal, which is sent to Domain B's ACS to continue the process until either party declines to continue or a trust contract is established.