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.

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.

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.

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.
In a fully compliant implementation the SID 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

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

See Identity Model for more detail on the use of OpenID consent to implement this flow.