This As the NSTIC work program evolves, we can expect to see multiple proposed solutions put forward that promise to deliver a new generation of online services. To the extent that the various solutions are competing for adoption, it will be necessary to evaluate them against each other for relative costs and benefits. Such comparisons will be quite challenging because proposed solutions will be built on disparate and seemingly incommensurable models (architectures, protocol stacks).
What follows 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 needfor the reasons cited above it will be important to be able to evaluate and compare one against the other.
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.
...
Table I: Atomic functionality required to implement a white pages editing and delivery tool with their composition under two different models:
Step | Name | Relevant actor actors or componentcomponents in SAML model | Relevant actor actors or componentcomponents in UMA model | Claim Identity|
---|---|---|---|---|
1 | Request to edit one's own protected White Page (WP) information | Person A as end user --> WP Editing App behind SAML SP | 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 | end user --> WP Client App on Resource Server (RS) | |||
2 | Challenge for Identity | AuthN Service fronting SAML IdP --> Person A as end user | Authorization Server (AS) protecting RS --> Person A as end user | |
3 | Claim Identity | Person A as end user --> AuthN Service fronting SAML IdP | Person A as Resource Owner --> Authorization Server (AS) protecting RS | |
4 | Verify Claimed Identity | Authentication Service fronting SAML IdP --> Person A as end user | AS protecting RS --> Person A as Requesting PartyResource Owner (RO) | |
5 | Grant Authorization to edit WP Information | WP Editing App behind SAML SP Authorization Server--> Person A as end user | AS protecting RS --> Person A as RO | |
6 | Edit WP Information | Person A as end user --> WP Editing App behind SAML SP | Person A as Resource OwnerRO --> WP Client App on RS | |
7 | Set Access Policy for WP Information | Person A as end user(Done on behalf of Person A by IdP admin per attribute release policy) | Person A as Resource OwnerRO --> AS | |
8 | Persist Access Policy for WP Information | SAML Attribute Release Config Files | AS | |
Authorization Server9 | Make WP Information Available Online | WP App | Resource Server | |
10 | Discover White Pages for given user | Person B as end user | Service Registration; Person B as Requesting Party | |
11 | Search/Find Person WP Information | Person B as end user | Person B as Requesting Party | |
12 | Request Authorization for WP Information Access | Person B as end user | Person B as Requesting Party | |
13 |
| |||
14 | Grant Authorization for WP Information Access per Policy | WP App behind SAML SP | Authorization Server | |
15 | Show WP Information | WP App | Resource Server or a Client of Resource Server |
...