http://tcwiki.azurewebsites.net/index.php?action=history&feed=atom&title=Relying_Party_Registration_Use_Case 2026-09-06T10:34:08Z Revision history for this page on the wiki MediaWiki 1.27.4 http://tcwiki.azurewebsites.net/index.php?title=Relying_Party_Registration_Use_Case&diff=5223&oldid=prev 2019-03-27T18:21:57Z

<p>Created page with &quot;==Full Title of Use Case== A collection of user journeys for any person that wants to register a personal account for authentication at a Relying Party. ==Context== To provid...&quot;</p> <p><b>New page</b></p><div>==Full Title of Use Case==<br /> A collection of user journeys for any person that wants to register a personal account for authentication at a Relying Party.<br /> <br /> ==Context==<br /> To provide a good user experience at any [[Relying Party]] [[Web Site]] that allows [[User]] [[Authentication]] by some provider that is not unique to that site.<br /> <br /> ===Goal===<br /> * The user has full capability to exercise their right to select an [[Identifier or Attribute Provider]] of their own choosing.<br /> <br /> ===Examples of Problems to be Addressed===<br /> <br /> The user cannot remember all of the user names and passwords that would be required if every site where they had consented to the storage of their information used their own scheme.<br /> <br /> ===Actors===<br /> #User<br /> #Relying Party<br /> #Provider of services related to [[Authentication]] or [[User Information]] sharing.<br /> <br /> ==Preconditions==<br /> # The user wants to control access to their own [[User Information]].<br /> # At least one [[Identifier or Attribute Provider]] exists that is acceptable to both the [[User]] and the [[Relying Party]].<br /> # The user will be able to use the registered account later at the [[Relying Party]], see wiki page [[Relying Party Authentication Use Case]].<br /> <br /> ==Scenarios / User Journeys==<br /> The goal of these scenarios is to test the functionality of any web site were the user access and update their information.<br /> <br /> Journey 1 - the user's comes to the site to learn what emergency access really is:<br /> <br /> <br /> Journey 2 - the user is directed to the site as they do want to start to collect contact data:<br /> <br /> <br /> Journey 3 - The user has already registered with the site.<br /> <br /> ==Results==<br /> Accepted Risks:<br /> #Data transfers involved work within a framework of trust and mutual understand as to the user's wishes with respect to care and privacy.<br /> #It is not clear how a non-responsive user can provide sufficient details to the First Responder. Presumably the existing First Responder network can provide some guidance on that challenge.<br /> <br /> Post Condition:<br /> #There are now two additional consents steps, lab with sensitive data and secondary provider with sensitive.<br /> #No data is ever shared with any provider that has not been strongly identified to the user.<br /> #The user results are available it is assumed that the consent receipt acknowledged that the data would be sent back to the primary care doctor.<br /> <br /> Examples:<br /> #tbd<br /> <br /> Dependencies::<br /> #Web Sites must be trusted before any user information is provided to them.<br /> #Trust federations can be used to help users make informed decisions.<br /> #User consent and trust must begin with no user information transferred.<br /> #Standards exist to collect needed attributes where-ever they may be.<br /> <br /> ==Workflow Diagram==<br /> TK<br /> <br /> ==References==<br /> <br /> [[Category:Use Case]]<br /> [[Category:Authentication]]</div>

Tom