Difference between revisions of "Bootstrapping Identity and Consent"
From MgmtWiki
(→User Identifier Provider in Cloud) |
(→User Identifier Provider in Cloud) |
||
| Line 21: | Line 21: | ||
* 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. | * To enable a persistent user identifier, this solution will use the term [[Subject]] ID (SID), following the terminology of the OpenID Connect specification. | ||
| + | |||
| + | Flows shown in diagram below for getting a SID and contact information with consent. | ||
| + | # User requests access and selects a method for getting a persistent ID | ||
| + | # Resource Owner provides the scope needed to allow access, it bounces to the source of the ID | ||
| + | # IAP asks user to provide consent to release contact info and SID to RP | ||
| + | # User grants consent | ||
| + | # IAP issues SID for the [[User]] ([[Subject]]) to the RP via the user as the IAP still (theoretically) doesn't have a connection to the RP | ||
| + | # RP uses the [[Authorization Code]] issued for the contact info | ||
| + | # IAP provides contact info and a consent receipt | ||
| + | # RP offers consent receipt to user | ||
| + | |||
| + | |||
| + | [[File:BootStrapID.png]] | ||
==References== | ==References== | ||
Revision as of 16:19, 7 July 2018
Contents
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.
Flows shown in diagram below for getting a SID and contact information with consent.
- User requests access and selects a method for getting a persistent ID
- Resource Owner provides the scope needed to allow access, it bounces to the source of the ID
- IAP asks user to provide consent to release contact info and SID to RP
- User grants consent
- IAP issues SID for the User (Subject) to the RP via the user as the IAP still (theoretically) doesn't have a connection to the RP
- RP uses the Authorization Code issued for the contact info
- IAP provides contact info and a consent receipt
- RP offers consent receipt to user
