!!! Overview[1]
[{$pagename}] is a digital [credential] technology for [claims]-based identity management invented by Stefan Brands and developed by Credentica.[1] 

[{$pagename}] simultaneously provides for strong [security], scalability, and [privacy] (including [anonymity]), and allows for [claims] to be efficiently tied to the use of [smart Cards]. In 2008, [Microsoft] acquired the technology, including all of the underlying patents, with the stated goal of opening it up.[1]

In March 2010, [Microsoft] announced the release of a [cryptographic] specification and [Open Source] [API] implementation code for part of the [{$pagename}] technologies as a Community Technology Preview under Microsoft's Open Specification Promise.[3]

[{$pagename}] is an innovative [cryptographic] technology that allows users to __minimally__ disclose certified information about themselves when interacting with online [Service Providers]. [{$pagename}] provides a superset of the security features of [Public Key Infrastructure] ([PKI]), and also provide strong [privacy] protections by offering superior user control and preventing unwanted user tracking.

A [{$pagename}] [token] is a type of [credential] similar to [PKI] [certificate] that can encode [attributes] of any type, but with two important differences:[2]
* The issuance and presentation of a [token] is unlinkable due to the special type of [Public Key] and [signature|Digital Signature] encoded in the token; the [cryptographic] "wrapping" of the attributes contain no correlation handles. This prevents unwanted tracking of users when they use their [{$pagename}] [tokens], even by colluding insiders.
* Users can minimally disclose information about what attributes are encoded in a [token] in response to dynamic verifier policies. As an example, a user may choose to only disclose a subset of the encoded attributes, prove that her undisclosed name does not appear on a blacklist, or prove that she is of age without disclosing her actual birthdate.

These user-centric aspects make the [{$pagename}] technology ideally suited to creating the digital equivalent of paper-based [credentials] and the plastic ID cards in one's wallet.

[{$pagename}] compiles with the [Law of User Control and Consent].

Microsoft has made available the foundational features of the technology by releasing the core U-Prove specifications under the Open Specification Promise.

!! Actors within [{$pagename}][3]
* [Issuer|Attribute Provider] - the [Attribute Provider] typically [Identity Provider (IDP)]
* [Prover] - the [end-user|user-agent] or a type of [Resource Owner]
* [Verifier] - typically a [Relying Party]

!! [{$pagename}] technology basics[3]
At the heart of the U-Prove technology is the notion of a [U-Prove token]. A [{$pagename}] [token] is a cryptographically protected collection of information of any kind (referred to as attributes). 

[U-Prove token] is issued by an [Issuer|Attribute Provider] to a [Prover] via an issuance protocol, and subsequently presented by the [Prover] to a [Relying Party] via a presentation protocol. 

Because a [U-Prove token]  is just a binary string it can be issued and presented over any electronic network. To perform the U-Prove [protocols], all participants require computing devices that function on their behalf.

!! Issuing a U-Prove token[3]
In order for a [Prover] to retrieve a [U-Prove token]  from an [Issuer|Attribute Provider] (authoritative source), the two parties must engage in an instance of the U-Prove issuance protocol. This is a cryptographic protocol that takes as its inputs, among others, any attributes to be encoded into the token. 

The innovative features of the U-Prove technology derive from the [cryptographic] design of the issuance protocol, which is based on advances in modern cryptography. For the purposes of this overview it suffices to know that the [Issuer|Attribute Provider]’s signature is not a conventional RSA or DSA signature, and that issuance is a three-leg interactive protocol enabling the [Prover] to hide certain token elements from the [Issuer|Attribute Provider] (authoritative source).

Prior to issuing a [U-Prove token]  to a [Prover], its [Issuer|Attribute Provider] (authoritative source) may assess the [Prover]’s eligibility to receive a token. In addition, the [Issuer|Attribute Provider] (authoritative source) may want to ascertain that the statements it will encode into the token pertain to the right [Prover]. These objectives may require the [Issuer|Attribute Provider] (authoritative source) to authenticate Provers (end-users) within its own domain or to verify other statements; nothing prevents the [Issuer|Attribute Provider] from relying on U-Prove tokens issued by other [Issuer|Attribute Provider]s.
%%information
All of these considerations are outside the scope of the U-Prove technology.
%%

The U-Prove issuance protocol enables the [Issuer|Attribute Provider] to protect U-Prove tokens against unauthorized manipulations, in accordance with application-specific requirements. The following basic protections are always in place:
* [Integrity] and [Non-Repudiation]: 
** Each issued [U-Prove token]  contains an unforgeable digital signature of its [Issuer|Attribute Provider] on the entire contents, created by the [Issuer|Attribute Provider] by applying its private key. 
** The [Issuer|Attribute Provider]’s signature serves as its authenticity mark on the U-Prove token enables anyone to verify that the [U-Prove token]  was issued by the [Issuer|Attribute Provider] and that its contents have not been altered.
* Replay attack prevention: Each issued [U-Prove token]  also contains a token-specific public key that is known only to the Prover. The [Prover] randomly generates it during the issuance protocol, together with a corresponding private key for the U-Prove token. In contrast to the token’s public key, this private key is not part of the U-Prove token; the [Prover] never discloses it when using the U-Prove token. 

In the next section we will explain how this prevents Verifiers from replaying presented U-Prove tokens. 

Beyond these basic protections, U-Prove tokens can be protected using various optional security measures.

The [Issuer|Attribute Provider] (authoritative source) may issue arbitrarily many U-Prove tokens by using the same private key, without any loss of security. The [Issuer|Attribute Provider]’s corresponding public key is part of the [Issuer|Attribute Provider] parameters; this public information should be available to anyone interested in verifying issued and presented U-Prove tokens. Conceptually, the [Issuer|Attribute Provider] (authoritative source) parameters are equivalent to the certificate of a [Certificate Authority] in a [Public Key Infrastructure].

!! Presenting a U-Prove token[3]
To present a [U-Prove token] to a [Verifier|Relying Party], the [Prover] and the [Verifier|Relying Party] engage in an instance of the U-Prove presentation protocol. The [Prover] provides the token attributes (or, as we will see in Section 4.3, only a subset of the attributes), the [Issuer|Attribute Provider]’s signature, and the token-specific public key. The [Prover] also sends a response to the [Verifier|Relying Party]. To compute this response the [Prover] applies the private key for the U-Prove token to a presentation challenge of the [Verifier|Relying Party]. This presentation challenge must include a:
* [nonce] - a unique number that is never reused; 
* timestamp or a counter appended to a unique Verifier identifier

We refer to the [Prover]-computed response as the presentation proof; it is a cryptographic proof of possession of the [private Key] corresponding to the presented U-Prove token. It proves that the [private Key] has been applied to the presentation challenge but the private key itself remains secret; this security guarantee holds even if all [Verifiers|Relying Party] and the [Issuer|Attribute Provider] participate in [collusion], examine arbitrarily many presentation proofs created with the same U-Prove token, and deviate from the issuance and the presentation protocols. As a result, [Verifiers|Relying Party] cannot replay the U-Prove tokens presented to them.

The verification of a presented [U-Prove token]  does not require any secret information, special-purpose hardware, or real-time communication with the [Issuer|Attribute Provider] or any other party; all that is needed is an authentic copy of the [Issuer|Attribute Provider] parameters under which the [U-Prove token]  was issued.

Upon verification of a presented U-Prove token, the rest of the session between the [Prover] and the Verifier may be securely tied to the initial authentication event.
%%information
how this is accomplished is outside the scope of the U-Prove technology. 
%%

By reusing the same [U-Prove token]  in subsequent visits to the same Verifier, the [Prover] can establish a relationship with the Verifier that spans multiple sessions. By using different U-Prove tokens on different occasions, on the other hand, the [Prover]'s activities can be segmented in a manner that protects the [Prover]'s privacy (even in the face of [collusions] involving the [Issuer|Attribute Provider]) and minimizes the risk of identity theft.

A [Prover] can create arbitrarily many presentation proofs with the same U-Prove token, within and across sessions with Verifiers, unless reuse limitations prevent such. This enables [Prover]s to securely re-authenticate to Verifiers using the same U-Prove token; see Section 3.5 for more information.

While [U-Prove tokens] do not require encryption over the wire to prevent replay attacks, [encryption] may nonetheless be desirable for message [confidentiality]. Depending on application requirements, [encryption] may
be applied to a token in its entirety or to selected token contents. 

%%information
[Encryption] is outside the scope of the U-Prove technology.
%%!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [U-Prove-Wikipedia|Wikipedia:U-Prove|target='_blank'] - based on information obtained 2015-11-07
* [#2] - [U-Prove|http://research.microsoft.com/en-us/projects/u-prove/|target='_blank'] - based on information obtained 2015-11-07
* [#3] - [U-Prove Technology Overview V1.1|http://research.microsoft.com/pubs/166980/U-Prove%20Technology%20Overview%20V1.1%20Revision%202.pdf|target='_blank'] - based on information obtained 2015-11-07