PD+-+F2F+Sprint+Team+Meeting+Minutes+2011-06-15+-+Query+for+Digital+Certificates+Use+Case


 * Date:** //06/15/2011//
 * Name:** //Provider Directories (PD)// Sprint Team F2F Meeting //- Query for Digital Certificates Use Case Session//

Agenda/Objectives:

 * **Topic** || **Time Allotted** ||
 * Query for Digital Certificate || 9:15am-12:00pm ||

Attendees:
Amram Ewoo, Galen Mulrooney, Michael Rossman, Nitin Jain, Robert Dieterle, Ryan Balsick, Sri Koka, Thompson H. Boyd, III, Veronica Yackuboskey, Vincent Lewis, Ken Pool, Melanie Combs-Dyer, Annamarie Saarinen, Lin Wan, Michael Nelson, Steve Rushing, Scott Chapin, Myung Choi, Stephen Witter, Tynisha Carter, Chris Andreou, Jonathan Tadese

Panelist Attendees:
Victoria Njoku, Virginia Riehl, Erik Pupo, Jitin Asnaani

Action Items:

 * **Date** || **Description** || **Status** || **Notes** ||
 * 6/16/2011 || Review and provide comments on sections completed i.e.
 * Scenarios
 * Base Flows
 * Use Case, Context, Activity, and Sequence Diagrams
 * Use Case Assumptions
 * Pre-conditions
 * Post-conditions
 * Actors and Roles
 * Functional Requirements
 * Information Exchange Requirements
 * System Requirements
 * Issues and Obstacles
 * Data Set Considerations || OPEN || n/a ||
 * 6/16/2011 || Review and provide comments on sections to complete during Friday PD Sprint Team meeting i.e.
 * Overview and Scope (includes: In Scope, Out of Scope, Background, Policy Issues, Regulatory Issues, Communities of Interest sections)
 * Challenge Statement
 * Value Statement || OPEN || n/a ||
 * 6/20/2011 || Assemble Use Case package for consensus during week of June 20th before handoff to Harmonization Team || OPEN || n/a ||

**Key Discussion Points:**

 * Multiple certificates could be returned for more than one reason
 * RFAC 4387 describes everything that we are stating, it should be used as a reference
 * This use case has been constrained to querying with an electronic address
 * There are multiple ways to express the user story
 * If you query and you get the URL, then you would use the URL to obtain the certificate
 * A statement needs to be added in the system requirements section stating that the system will know what certificates to use – this could be added as an assumption
 * It is possible in step 2 of the activity diagram that there can be information received external to the provider directory and then returned to the provider directory
 * Sprint Team agreed that functional requirements section required no changes
 * The certificate ties to an identity. The certificate needs to be bound to an identity
 * The sequence diagram will reflect changes discussed in the scenario, use case, and context i.e. the synchronous messaging
 * Transport mechanism will provide guaranteed delivery and error handling is out of scope ( this will be moved to the out of scope section of the use case)
 * Include in the definition that Digital Certificate(s) has metadata information
 * The query doesn’t care if it is federated or not. The use case does not need to address federation, it should also be out of scope
 * Sprint Team agreed that the post conditions section required no changes
 * There is no mechanism to verify whether a certificate authority is valid without a trust anchor without a certificate directory- (move to assumptions)
 * Access to public keys will be constricted
 * Add definition for public key in the Use Case
 * The data set section should address sending a security artifact that is encrypted with a private key
 * We are using an electronic address to get a digital certificate for a push transaction and they require that

**Resolution(s):**

 * The following assumption was added to the Use Case
 * More than one certificate can be retrieved from the certificate store
 * The following assumption was added to the Use Case
 * There can be multiple certificates both digital certificates and encryption
 * Change “certificate” to certificate(s)
 * Change the word “send” to “return”
 * All references to “certificate store” have been changed to “certificate directory” (we have the intent that the certificate is bound to an identity).
 * Changed actor name in the base flow step 1 to “certificate directory consumer”
 * Changed the event /description in the base flow to the following “Sends digital certificate(s) associated with the electronic address for the provider for interest”.
 * The Use Case assumption section now reflects the following changes
 * Bullet 2: “external provider directories” has been changed to “external certificate directory”.
 * Bullet 3: “provider directory searches” has been changed to “certificate directory service”
 * Bullet 4: “public key information” has been changed to “certificate information”
 * Bullet 5: “provider directory system” has been changed to “certificate directory system”
 * Bullet 6: "provider directories” has been changed to “certificate directory”
 * Bullet 7: the following statement was added to the sentence “based on the relying party agreement, legal and governance”
 * The following assumption was added “the certificate directory and certificate authority must be part of and approved trusted framework”
 * Deletion of HIPPA from bullet 11
 * The following assumption was added “a certificate store will provide at least one secured, guaranteed delivery transport mechanism”.
 * “Applicable” was added to the following statement “all Federal, State & local regulations are being supported”
 * In the Pre-conditions section the following changes have been made
 * “Certificate Information Store that should receive a query” has been changed to “certificate directories that may receive a query”
 * “Provider information directories are available and can respond to queries” has been changed to “certificate directories that the provider system uses”
 * In the actors and roles section the following changes have been made
 * “Provider address” has been changed to “destination electronic address”
 * In the issues and obstacles section the following changes have been made
 * “There are a number of issues that will impact the implementation of this use case” has been changed to “Issues that may impact the implementation or effectiveness of this use case”
 * Removed the statement “The current status of existing standards, e.g., HL7 services specification is in RFI status at OMG”
 * Removed the statement “The need to standardize data and messaging for other uses of provider directories”
 * Added “providers are not broadly experienced in acquiring and using certificate”
 * In the dataset and considerations the following changes have been made
 * “provider identification information” has been changed to “provider destination”
 * Add: sending transaction (section description), Security artifact encrypted with the senders private key (data element), this will probably bear the digital certificate (additional notes)
 * “Digital Certificate Information” has been changed to “Digital Id of sender’s digital Certificate” data element is “electronic address of sender and additional notes state “this is not encrypted

//Parking Lot Items://

 * Federal bridge
 * Returning multiple certificates: returns one certificate verses multiple
 * Synchronous VS asynchronous
 * This could be a zero if no certificate is found and can send multiple certificates. A return of zero certificate could be a result of a denial or no certificates
 * API
 * Messaging framework
 * Add-provider systems will be able to interact with user to resolve ambiguous (out of scope)