This is intended as a first step toward an analytical framework that would allow us to meaningfully compare and contrast widely different solutions to given usage scenarios in the general space of web security. To take an example a SAML-based solution to a given problem might initially appear quite orthogonal to UMA-based solution to the same problem. Yet in ambitious ventures such as NSTIC that aim to facilitate a new generation of online services, meaningful comparisons between drastically different and seemly incommensurable proposed solutions will be a common need.
A prerequisite step will be to define a spanning set of atomic functions (technology and protocol-agnostic to the degree possible) that can be shown to be composable in different ways that correspond to familiar protocol-based solution families.
The following is offered as an introductory example. Imagine that a university offers students a service they can use to manage their white-pages entry in the online campus directory. The service allows the student to specify which elements of his/her white pages information should be viewable by anyone and which should be viewable only by faculty, staff and students at institutions within a specified set.
Table I: Atomic functionality required to implement a white pages editing tool and associated online white pages with their composition under two different models:
| Name | Relevant actor or component in SAML model | Relevant actor or component in UMA model |
|---|---|---|
| Claim Identity | Person A as end user | Person A as Resource Owner |
| Verify Claimed Identity | Authentication Service fronting SAML IdP | Authentication Service fronting Resource Server |
| Request Authorization to edit White Page (WP) Information | Person A as end user | Person A as Requesting Party |
| Grant Authorization to edit WP Information | WP Editing App behind SAML SP | Authorization Server |
| Edit WP Information | Person A as end user | Person A as Resource Owner |
| Set Access Policy for WP Information | Person A as end user | Person A as Resource Owner |
| Persist Access Policy for WP Information | SAML Attribute Release Config Files | Authorization Server |
| Make WP Information Available Online | WP App | Resource Server |
| Discover White Pages for given user | Person B as end user | Service Registration; Person B as Requesting Party |
| Search/Find Person WP Information | Person B as end user | Person B as Requesting Party |
| Request Authorization for WP Information Access | Person B as end user | Person B as Requesting Party |
| Grant Authorization for WP Information Access per Policy | WP App behind SAML SP | Authorization Server |
| Show WP Information | WP App | Resource Server or a Client of Resource Server |
This simple example already highlights some differences between a SAML-based solution and an UMA-based solution. Note that functions performed by the WP App in the SAML model are carried out by more than one component in the UMA model. This helps explain the need in the UMA model for a protocol for cooperatively provided services–The Resource Server and Authorization Server need to collaborate to accomplish the usage scenario. Conversely the comparison highlights that some elements of the usage scenario are "out of band" with respect to the SAML model. A full solution would have to be "SAML plus".