View source for Attribute proofing at AP

=== Overview ===
'''Scenario Name''': Attribute proofing at AP<br/>
'''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. <br/>
'''Corresponds to''': Interaction C in [[Basic interactions in a single Trust Framework|Scenario: Basic Interactions]]<br/>
'''Use cases''': [[Identity Proofing Use Case|Use case #3]] ??<br/>
<br/><br/>
'''Variations''':<br/>
#Direct authorization
#Delegated authorization
#One-time Vs. Stored authorization
<br/><br/>



====High-level====
At a high-level, Attribute Provider interactions may look like this
[[File:IntWG_APInteractions_01.png]]
<br/><br/>

'''AP composition''': So, going by OAuth model (used in UMA too - [https://docs.kantarainitiative.org/uma/draft-uma-core.html UMA core]), is AP just one entity, or a composition of resource server and authorization server?<br/>
To some extent, decomposition into Resource Server and Authorization server need not be made, but we may definitely need that distinction for interoperability.<br/>
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]]<br/><br/>
'''Question:''' Is the user coming here proactively, or after having been prompted to do so by an IdP or RP?<br/>
'''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?
<br/><br/>

====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''':
<br/><br/>

====Registering attributes====
'''Question''': Is the user selecting to store attributes of their choice, or is AP providing a list of attributes they support?
<br/><br/>