View source for Publicly Discoverable ePayment Address(es) Part 3

'''Title''': Publicly Discoverable ePayment Address(es) Part 3, LOOKUP

<br />
'''Use Case Description''': Minimal API consisting of a secureXML interface split into two separate interfaces: Registration & Query ('''Lookup'''). Query involves only “Lookup User” to resolve PII, GLID into LCA-PAN, LCA-ACH or Linked GLID


'''Purpose:''' To employ simple design characteristics that can be implemented without delay to a.) enhance safety and security by minimizing the ability for illegitimate (fabricated or stolen) identities to acquire identifiers with attributes having sufficient trust to utilize monetary and high value information asset transfer services; b.) enhance privacy by minimizing the risk that high-trust, private financial identifiers such as bank account or card numbers are unnecessarily divulged and therefore put at some risk to be improperly used to effect monetary or high value information asset transfer services without account-owner's authorization and c.) lay the groundwork for later extensions by Financial Institutions to enhance legitimate identities ability to assert ownership rights and privacy permissions pertaining to the use of cloud-based transactional data.

<br />
'''Use Case Category''': Trust/Assurance, Authentication, Interoperability, Privacy

<br />
'''Contributors ''': Richard O'Brien - [http://www.paymentpathways.com Payment Pathways, Inc.],
Peter Tapling - [http://www.marketwatch.com/story/authentify-recognized-as-a-visionary-in-gartner-2013-magic-quadrant-for-user-authentication-2013-04-16 Authentify, Inc.], and 
Peter Gordon - [http://www.fisglobal.com FISGlobal] & [http://www.fisglobal.com/products-paymentnetworks-paynet PayNet]
<br />
=== Use Case Details ===
'''Actors''': Financial institutions, Relying parties, eCommerce Companies, Identity Providers, Authoritative Parties

<br />
'''Goals''': 1)	Timely access to publicly discoverable ePayment addresses by Relying Parties on behalf of payers.

2)	Fraud reduction which may imply cost reduction for the relying party.
Viable business model for the relying party.

<br />
'''Assumptions''': The relying party supports access and revocation of access

<br />
'''Requirements''': Internet access device, identity information for the authorizing user and identity information of the relying party.

<br />
'''Process Flow''': 1)	The user intending to make a payment accesses the relying party with authentication as required by the relying party.

2)    The user wishes to pay another user or business:
     a)	The financial institution’s payment application queries the registry to validate the intended recipient is registered and equipped to receive at least one class of epayment 
(e.g. next banking day payment, instant payment; domestic, international, etc.)

     b)	The payment application finds the recipient in the registry, confirms with the payer that the personal identifiers are those of the intended recipient.

     c)	The payment application creates a money transfer using the validated ePayment address of the payment network supporting the desired class of service.

3)    The money transfer instruction is delivered to the appropriate payment network in the normal manner

<br />
'''Success Scenario''': 1)	Trusted ePayment Addresses discovered and/or validated.

2)       Trusted ePayment Addresses not found.

<br />
'''Error Conditions''': 1)	The payer does not have the credentials required by the Relying Party’s portal. Mitigation: the relying party to allow manual lookup
2)       Identity Provider does not support revocation. GLID permanently unavailable.


<br />

=== Relationships ===

Extension of: 
* Publicly Discoverable ePayment Address(es) Part 1 ENROLLMENT
* Publicly Discoverable ePayment Address(es) Part 2 UPDATE AND REVOCATION

GRAPHIC 1: [https://www.idecosystem.org/idesgwiki/images/3/39/High_Level_Economic_Model_ePayment_Address_Registry.pdf High Level Economic Model ePayment Address Registry]

GRAPHIC 2: [https://www.idecosystem.org/idesgwiki/images/f/ff/Greenlist_in_the_NSTIC_IDEcosystem.pdf Greenlist in the NSTIC IDEcosystem]

GRAPHIC 3: [https://www.idecosystem.org/idesgwiki/images/9/95/2013APR22_PayNet%27s_Greenlist_Benefits.pdf PayNet's Greenlist Benefits]

GRAPHIC 4: [https://www.idecosystem.org/idesgwiki/images/9/96/2013APR_22_PayNet%27s_Greenlist_Benefits.pdf Greenlist Benefits for Stakeholder Groups]

GRAPHIC 5: [https://www.idecosystem.org/idesgwiki/images/c/cc/2013APR22_PayNet_Launch_Schedule.pdf PayNet Launch Schedule]

=== References and Citations ===
* Enhanced System for Electronic Funds Transfer and Elimination of the Payee’s Need for Encryption and Privacy
US Patent No. 7,831,490 Modigliani, O’Brien and Vitagliano claim a computer implemented method of conducting monetary asset transfer transactions associating a unique identifier with payment address that can only be debited by the accountholder.  Such directories containing identifiers and payment addresses are synchronized to a root directory to enable non-repudiable deposits.
* Methods and Systems for Identity Authentication
US Patent No. 7,945,511  O’Brien, Gallant, et al claim a computer implemented method of conducting informational asset transfer transactions where a registry of unique identifiers are associated with informational assets and access to said assets is regulated in accordance with guidelines established by communities of interest functioning as registrars.
<br />


[[Category:Identity Management Use Cases]]
[[Category:Use Cases]]