Difference between revisions of "Bootstrapping Identity and Consent"

From MgmtWiki
Jump to: navigation, search
(User Identifier Provider in Cloud)
(User Identifier Provider in Cloud)
Line 20: Line 20:
 
* The user is required to have a persistent identifier on the RP for reasons that are made clear to the user.
 
* The user is required to have a persistent identifier on the RP for reasons that are made clear to the user.
 
* By the requirements of notification and recovery, this solution will describe some channel to the user, such as email or phone, other notification means are left for other solution descriptions.
 
* By the requirements of notification and recovery, this solution will describe some channel to the user, such as email or phone, other notification means are left for other solution descriptions.
 +
* To enable a persistent user identifier, this solution will use the term [[Subject]] ID (SID), following the terminology of the OpenID Connect specification.
  
 
==References==
 
==References==

Revision as of 11:42, 7 July 2018

Full Title or Meme

A ceremony must be performed to establish identifiers and contact information among communicating parties before any other interactions can commence.

Context

  • Given the greatly increased legislation that enforces the privacy rights of users of digital communications, some means is needed to identify and contact the parties to a covered interchange.

Problems

  • Any identifying information about a user must not be released without that user's or a guardian's consent.
  • At the end of the ceremony all parties have agreed and consented to their respective identifiers, contact methods and a trust relationship among them.

Solutions

User Identifier Provider in Cloud

  • Where the user is on a device and the user's Identifier or Attribute Provider (IAP) is in the cloud, that provider will also have, at a minimum, user contact information to enable user Recovery and Redress.
  • No restriction is placed on whether the user has ownership of the provider, or of their own information on the provider, for this solution to function as required.
  • The user navigates to the Resource service on the web, here called a Relying Party (RP) because it relies on information from the IAP.
  • The user is required to have a persistent identifier on the RP for reasons that are made clear to the user.
  • By the requirements of notification and recovery, this solution will describe some channel to the user, such as email or phone, other notification means are left for other solution descriptions.
  • To enable a persistent user identifier, this solution will use the term Subject ID (SID), following the terminology of the OpenID Connect specification.

References