Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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:

StepName

Relevant actors or components

in SAML model

Relevant actors or components

in UMA model

1Request to edit one's own protected White Page (WP) informationPerson A as end user --> WP Editing App behind SAML SPPerson A as end user --> WP Client App on Resource Server (RS)
2Challenge for IdentityAuthN Service fronting SAML IdP --> Person A as end userAuthorization Server (AS) protecting RS --> Person A as end user
3Claim IdentityPerson A as end user --> AuthN Service fronting SAML IdPPerson A as Resource Owner --> Authorization Server (AS) protecting RS
4Verify Claimed IdentityAuthentication Service fronting SAML IdP --> Person A as end userAS protecting RS --> Person A as Resource Owner (RO)
5Grant Authorization to edit WP InformationWP Editing App behind SAML SP --> Person A as end userAS protecting RS --> Person A as RO
6Edit WP InformationPerson A as end user --> WP Editing App behind SAML SPPerson A as RO --> WP Client App on RS
7Set Access Policy for WP InformationPerson A as end user(Done on behalf of Person A by IdP admin per attribute release policy)Person A as RO --> AS
8Persist Access Policy for WP InformationSAML Attribute Release Config FilesAS
Authorization Server9Make WP Information Available OnlineWP AppResource Server
10Discover White Pages for given userPerson B as end userService Registration; Person B as Requesting Party
11Search/Find Person WP InformationPerson B as end userPerson B as Requesting Party
12Request Authorization for WP Information AccessPerson B as end userPerson B as Requesting Party
13
  • (Repeat steps 1-5 substituting Person B as Requesting Party for Person A as Resource Owner)
   
14Grant Authorization for WP Information Access per PolicyWP App behind SAML SPAuthorization Server
15Show WP InformationWP AppResource Server or a Client of Resource Server

...