View source for Bootstrapping Identity and Consent

==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 [[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==

# See [[Identity Model]] for more detail on the use of [[OpenID Connect]] to implement this flow.

[[Category: Glossary]]
[[Category: Identifier]]
[[Category: User Experience]]
[[Category: Consent]]