[Openid-specs-ab] Issue #1415: re-using ID Token as a source of third party attested user-claims (openid/connect)

[Kristina Yasuda]

New issue 1415: re-using ID Token as a source of third party attested user-claims
https://bitbucket.org/openid/connect/issues/1415/re-using-id-token-as-a-source-of-third

Kristina Yasuda:

There have been multiple use-cases where ID Token is considered to be used as a mechanism to transport user claims across domains. In other words, RP1 who received an ID Token from IdP1 is reusing it as a source of user claims at RP2. 

Yes, as you might already be thinking ID Token as-is cannot be used in this manner. Which is why the implementations considering such use are exploring following extensions. 

Assuming that for an artifact to be able to transport user claims across domains, the following three pieces of information need to be included:

1. claims about the user
2. information about the user’s control over the private key, that the user can use to prove possession when presenting ID Token to a third party \(RP2\)
3. a signature over the above information by an entity \(IdP1\) that is trusted by the third party receiving an artifact \(RP2\)

1 and 3 are already in the ID Token. The question becomes how to includes 2. 

* One suggestion might be for an IdP to issue a signed JWT from the userInfo endpoint that includes the user’s \(RP1’s\)  
  public key in a "cnf" claim. RP1 can prove possession of this JWT by signing it over with a private key tied to the public key in `cnf` claim. \(this one is not exactly re-using ID Token\) 
* Another is to sign a nonce generated by a RP1 with a private key of the user. This nonce will be opaque to IdP1, but RP2 will be able to verify it using user’s public key passed in the PoP alongside ID Token.

To answer an inevitable question on the use-cases. 

* One use-case is user directly proving her identity to the application using ID Token from the IdP, when the IdP does not want to be involved in the process to avoid knowing when the user is using the app \(confirming if I can quote concrete company name\). 
* Another use-case is issuance of Verifiable Credentials, where the user wants to present an ID Token from IdP1 to the Issuer as an input information to the VC that is issued. Ideally you would want to use another VC as such an input, but in reality, there are much more ID Token being issued than VCs, so using ID Tokens for such purpose makes more sense. 

Yes, as some of you might be thinking, this brings ID Token very close to the functionality Verifiable Credentials have.

‌