Difference between revisions of "Bootstrapping Identity and Consent"
From MgmtWiki
(→Context) |
(→References) |
||
| (34 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | A | + | A [[Ceremony]] must be performed to establish identifiers and contact information among communicating parties before any other interactions can commence. |
==Context== | ==Context== | ||
| Line 12: | Line 12: | ||
==Solutions== | ==Solutions== | ||
| + | First we must know that the physical devices that are used are trust-worthy. See the paragraph [[Trust#Bootstrapping Trust from the User's Device|Boot-strapping Trust from the User's Device]] for more detail about that. | ||
| + | |||
| + | There many be multiple use cases with different solutions. Here is one use case. | ||
| + | ===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 use case solutions. | ||
| + | * To enable a persistent user identifier, this solution will use the term [[Subject]] ID (SUB), following the terminology of the OpenID Connect specification. | ||
| + | * In a fully compliant implementation the SUB is a pairwise unique identifier for the user that is only known to the RP and IAP and so cannot be used for tracking elsewhere. | ||
| + | * Also the user will be presented with a list of the scope of attributes requested by the RP. If more than contact information is requested, the user should be able to select which data to release. | ||
| + | * In any case, the RP should give the user the ability to provide alternate contact information whenever the user feels the need to do so. | ||
| + | * This use case does not go into user profile updates, [[Recovery]] or [[Redress]] which would be required in any deployed system. | ||
| + | * Strong binding between the authorization code and the RP is available in most protocols, but is not strictly necessary for this use case. | ||
| + | |||
| + | Flows shown in diagram below for getting a SUB and contact information with consent. The flows and redirect are arranged to provide no information to the RP until the user consents to the transfer. | ||
| + | # 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 and attributes. | ||
| + | # IAP presents the requested scope to the user and asks user to provide consent to release SUB and other requested attributes to the RP. | ||
| + | # User grants whatever consent they are comfortable with releasing. It is up to the RP to determine if the released information is adequate to authorize access. | ||
| + | # IAP issues SUB 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 information and other attributes as released by the user only if the RP is willing to authorize access. | ||
| + | # IAP provides the attributes (at a minimum the contact info) and a consent receipt. | ||
| + | # RP offers consent receipt to user. | ||
| + | |||
| + | |||
| + | [[File:BootStrapID.png]] | ||
==References== | ==References== | ||
| + | # See [[Identity Model]] for more detail on the use of [[OpenID Connect]] to implement this flow. | ||
| − | [[Category:Glossary]] | + | [[Category: Glossary]] |
| + | [[Category: Identifier]] | ||
| + | [[Category: User Experience]] | ||
| + | [[Category: Consent]] | ||
Latest revision as of 14:37, 1 February 2022
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
First we must know that the physical devices that are used are trust-worthy. See the paragraph Boot-strapping Trust from the User's Device for more detail about that.
There many be multiple use cases with different solutions. Here is one use case.
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 use case solutions.
- To enable a persistent user identifier, this solution will use the term Subject ID (SUB), following the terminology of the OpenID Connect specification.
- In a fully compliant implementation the SUB is a pairwise unique identifier for the user that is only known to the RP and IAP and so cannot be used for tracking elsewhere.
- Also the user will be presented with a list of the scope of attributes requested by the RP. If more than contact information is requested, the user should be able to select which data to release.
- In any case, the RP should give the user the ability to provide alternate contact information whenever the user feels the need to do so.
- This use case does not go into user profile updates, Recovery or Redress which would be required in any deployed system.
- Strong binding between the authorization code and the RP is available in most protocols, but is not strictly necessary for this use case.
Flows shown in diagram below for getting a SUB and contact information with consent. The flows and redirect are arranged to provide no information to the RP until the user consents to the transfer.
- 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 and attributes.
- IAP presents the requested scope to the user and asks user to provide consent to release SUB and other requested attributes to the RP.
- User grants whatever consent they are comfortable with releasing. It is up to the RP to determine if the released information is adequate to authorize access.
- IAP issues SUB 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 information and other attributes as released by the user only if the RP is willing to authorize access.
- IAP provides the attributes (at a minimum the contact info) and a consent receipt.
- RP offers consent receipt to user.
References
- See Identity Model for more detail on the use of OpenID Connect to implement this flow.
