View source for Pairwise Identifier

==Full Title or Meme==
An extension of [[OpenID Connect]] to enforce a unique [[Subject]] Identifier for each provider/client (IdP/Relying Party) pairing.
==Context==
*Common implementations of the [[OpenID Connect]] protocol lets the [[Identifier or Attribute Provider]] select an opaque [[Identifier]] for each user which is used in all federated identification with [[Relying Party|Relying Parties]].
*The [[OpenID Connect]] protocol is always among three parties: the [[User]] (called subject), the [[Relying Party]] (called client for OAuth compatibility) and the [[Identifier or Attribute Provider]] (called OpenID Provider).
*There are always three [[Identifier]]s: the subject id (sub), the client id (client_id), and a URL pointing to an authoritative set of configuration parameters of the OpenID Provider (OP).


===To be integrated===
Note that in the Open ID document the RP is called a client and the IdP is called an Open ID provider (OP). It is a long-term goal for the [[IDEF]] to create an OpenID Connect profile that shows which options to use. In the meantime the [[Compliant Implementation of RP on ASP.NET]] provides a working model of a compliant OpenID Connect implementation. The following items might be included in a [[IDEF]] profile:
#The RP and not the user has the ability to determine how the unprotected flow of access tokens are handled. [[IDEF]] could require the use of the "Authorization Code Flow", as shown above, which places all access tokens in protected flows between the RP and the IdP. That presumes that the RP is able to protect secrets like the [[User Private Information]] from disclosure.
#The RP determines which [[User Private Information]] it wishes to receive and leaves it up to the IdP to determine whether the user has any choice as to which information to disclose. Some IdPs are very diligent and allow the user to select based on the claims profiles provided by the RP. It is more common for IdPs to offer the list of requested claims profiles to the user on a "take-it-or-leave-it" basis. the [[IDEF]] could require IdPs to give the user more granular control.
#The Subject Identifier (sub in OpenID) is provided from the IdP to the RP during authentication. It is not a requirement that the IdP avoid reuse the same "sub" between two RP's to prevent linking between [[User Object]]s in those two RPs unless "pairwise" is specified. Any [[IDEF]] profile should require [[Pairwise Identifier]]s for subject as it is not in the interest of any digital entity to enable it. See the wiki page on [[Pairwise Identifier]] for the pros and cons of this approach.


==Problems==
These are issues that the [[OpenID Connect]] core specification leaves up the the implementer to chose that create [[Security]] or [[Privacy]] problems.
#The [[Subject]] ID may be ephemeral. The following quote is from Draft profile FAPI Pt 2 " While the name ID Token suggests that it is something that provides the identity of the resource owner (subject), it is not necessarily so. While it does identify the authorization server by including the issuer identifier, it is perfectly fine to have ephemeral subject identifier. In this case, the ID Token acts as a detached signature of the issuer to the authorization response and it was an explicit design decision of OpenID Connect Core to make the ID Token act as a detached signature. "
#The [[Subject]] ID (sub) may be shared among all of the clients that use the same OP unless pair-wise sub is included in the meta-data.
#The [[Identifier or Attribute Provider]] may optionally ask for [[User Consent]] and may provide any set of claims they deem appropriate.

==Solutions==
These are additional limitations that need to be provided to the [[OpenID Connect]] implementation to meet existing legislation for the 3 party problem.
*Security Profile:
#The [[Subject]] ID (sub) must be persistent and not used for different users for at least one year after it use is no longer used for its most recent [[Subject]].
#The [[Subject]] ID (sub) must not be shared with different clients by implementing pair-wise identifiers in the OP.
#The [[Identifier or Attribute Provider]] must not provide any claims to the [[Relying Party]] that have not been part of an [[User Consent]] approval process.
===Pros===
===Cons===
It is difficult for the [[Relying Party]] to aquire claims from any [[Attribute]] (Claims) provider that is distinct from the [[OpenID Connect]] provider as the [[Attribute]] Provider should not be tracking the user when a [[Pairwise Identifier]] is being used.

==References==
#[[OpenID Connect]] specifications (use this if you want to be sure you have the latest version): http://openid.net/developers/specs/
#[[OpenID Connect]] core specification with Errata Set 1 (2014-11-08): http://openid.net/specs/openid-connect-core-1_0.html

[[Category:Glossary]]
[[Category:Standard]]
[[Category:Authentication]]