Attribute proofing at AP
Overview
Scenario Name: Attribute proofing at AP
Scenario Description: In this step, the user proves to a particular AP that they own certain attributes (more like attribute-value pairs). The AP then registers those attribute values against the digital identity provided by the user (after verifying the user's ownership of that specific digital identity, possibly through some login process that involves the IdP). Additionally, the AP may register the specific credential (type) used to register the attribute(s), and thus require same (type of) credential at the time of access.
Corresponds to: Interaction C in Scenario: Basic Interactions
Use cases: Use case #3 ??
Variations:
- Direct authorization
- Delegated authorization
- One-time Vs. Stored authorization
High-level
At a high-level, Attribute Provider interactions may look like this
File:IntWG APInteractions 01.png
AP composition: So, going by OAuth model (used in UMA too - UMA core), is AP just one entity, or a composition of resource server and authorization server?
To some extent, decomposition into Resource Server and Authorization server need not be made, but we may definitely need that distinction for interoperability.
Question is 'what do we do for interaction flows'? Note that UMA and OAuth do not explicitly talk about attribute proofing, registration, particularly in IDEF point-of-view.
Discover, Reach, Assurance
See Discover, Reach, Assurance in Registration and credentialing
Question: Is the user coming here proactively, or after having been prompted to do so by an IdP or RP?
In other words: Is this an explicit step in the IDEF, or an optional step??? If optional, who else is providing this functionality (attribute storage, authorized release, etc.) - is it the RPs, or IdPs?
IdP Login
The AP is not the IdP (role-wise), thus it will rely on an (external) IdP for user authentication and identity. (Note: This probably is going to be no different from IdP login at an RP - actually, in this case, AP is the RP.) Data: IdP provides a single, persistent identifier for the user. Note: AP MAY support mapping of multiple identifiers (from same IdP or different IdPs) to the same 'account' at the AP (like any RP).
See RP interactions for more details on login with IdP:
Registering attributes
Question: Is the user selecting to store attributes of their choice, or is AP providing a list of attributes they support?