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 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.

1. User requests access and selects a method for getting a persistent ID.
2. Resource Owner provides the scope needed to allow access, it bounces to the source of the ID and attributes.
3. IAP presents the requested scope to the user and asks user to provide consent to release SUB and other requested attributes to the RP.
4. 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.
5. 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
6. 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.
7. IAP provides the attributes (at a minimum the contact info) and a consent receipt.
8. RP offers consent receipt to user.

References

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