Policy-Based Access Control - Revision history

Tom: /* Context */

2026-01-03T23:13:50Z

‎Context

2025-10-15T02:00:29Z

2025-10-15T01:47:36Z

2025-08-02T17:23:53Z

‎Other bases for Access Control

2025-08-02T17:23:27Z

‎Other forms of Access Control

2025-08-02T17:20:56Z

‎Other forms of Access Control

2025-08-02T17:19:26Z

‎Other forms of Access Control

2025-08-02T17:16:50Z

‎Other forms of Access Control=

2025-08-02T17:16:13Z

‎Other forms of Access Control=

2025-08-02T17:13:44Z

‎Solution

@@ Line 4: / Line 4: @@
 ==Context==
-* This wiki applies specifically to policy expressed digitally in communications protocols; not that in human resources policies.
+* This wiki applies specifically to policy expressed digitally in communications protocols that require access to a resource; not that in human permission policies.
 * The most common [[Attribute]]-Based Access Control language [[Policy Language#XACML|XACML]] expanded their scope in version 3.0 to include the description [[Policy-Based Access Control]] although policy statement was defined in earlier versions.

@@ Line 31: / Line 31: @@
 The second frame shows the same policy control but moves the Policy Enforcement Point (PEP) to the client device computer. This assumes that the device is trusted by the PDP to faithfully enforce the policy.
-[[File:PolicyFLowsX2.png]]
+[[File:PolicyFLowsX2.png|800px]]
 ===User Experience===

@@ Line 19: / Line 19: @@
 ===Other Bases for Access Control===
 A personal view:
-  TBAC = policy comes with the token (=ticket)
+  TBAC = policy comes with the token (= ticket)
   PBAC = policy flows by its own path
   RBAC = roles bundle policy into identity labels
@@ Line 29: / Line 29: @@
 Policy can be made at the government level or by a resource owner. When a user is attempting to access some digital resource or some real-world venue, it is typically important for the user to know if they have the credentials to achieve their objective in advance.  For example, in the [https://kantarainitiative.org/confluence/display/PEMCP/Biometric+Pre+Check Biometric Pre-Check use case] the traveler (denoted as the holder in the image below) is expected to be able to determine if they can pass through the check-in line before they even leave home for the airport. The solid lines in the figure below are data transfers. The dotted lines are physical presentations, not all of which are required in every case.
-[[File:PolicyFLows.png]]
+The second frame shows the same policy control but moves the Policy Enforcement Point (PEP) to the client device computer. This assumes that the device is trusted by the PDP to faithfully enforce the policy.
 ===User Experience===

@@ Line 17: / Line 17: @@
 * [https://github.com/thecardeaproject/cardea Cardea on GitHub.]
-===Other bases for Access Control===
+===Other Bases for Access Control===
 A personal view:
   TBAC = policy comes with the token (=ticket)

@@ Line 17: / Line 17: @@
 * [https://github.com/thecardeaproject/cardea Cardea on GitHub.]
-===Other forms of Access Control===
+===Other bases for Access Control===
 A personal view:
   TBAC = policy comes with the token (=ticket)

@@ Line 21: / Line 21: @@
   TBAC = policy comes with the token (=ticket)
   PBAC = policy flows by its own path
-  RBAC = the role bundles policy into identity label
+  RBAC = the role bundles policy into identity labels
 ==Solution==