Changes to the PoP Token flow

[jaxoncreed]

Notes from Justin Richer:

The current flow the PoP tokens can be kept with these changes:

• Use access tokens rather than id tokens (Don't present an id token to a third party)
• Change signatures to model DPoP or Cavage Signatures or HTTP signatures for OAuth Proof of Possession.

[jaxoncreed]

DPoP Draft Proposal: https://tools.ietf.org/html/draft-fett-oauth-dpop
Cavage Signatures Draft: https://tools.ietf.org/html/draft-cavage-http-signatures

[dmitrizagidulin]

To summarize:

1. Switch Proof of Possession mechanism from current nested PoP token to use the DPoP draft spec (use of two headers, an Authorization header and a DPoP header).

2. Instead of re-using the ID Token for the Multi-RS use case, the RP can request an Identity Credential in the ID Token (using the usual claims or scopes mechanism). The ID Credential (in W3C VC format, encoded as a JWT), will be returned in the id_vc claim in the ID token.

Example ID Token with the credential:

{
  "iss": "https://idp.example.com",
  "sub": "https://janedoe.com/web#id",
  "aud": "https://client.example.com",
  "nonce": "n-0S6_WzA2Mj",
  "exp": 1311281970,
  "iat": 1311280970,
  “id_vc”: <reusable ID credential, in Verifiable Credentials format, encoded as a JWT>
}

Decoded id_vc, a re-usable identity credential, for use with DPoP headers:

{
  "sub": "https://janedoe.com/web#id",    <- Web ID / DID
  "iss": "https://idp.example.com",
  "aud": "https://client.example.com", // audience constrained to the client / presenter
  "iat": 1541493724,
  "exp": 1573029723,  <- identity credential expiration (separate from the ID token)
  "capability_uri": "https://idp.example.com/caps/12345",
  "cnf":{
         // DPoP public key confirmation, per DPoP spec section 7
       "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"  
  }
}

This ID Credential is what will be re-used (with appropriate audience constraints) with the appropriate Proof of Possession mechanism (from item 1).

[elf-pavlik]

Currently id_token gets signed by the issuer and pop token that wraps it gets signed by the client. I understand that with new approach we get:

• OIDC mandated signing of id_token by OP, which only goes and gets verified by the client (never goes to RS)
• VC mandated signing of verifiable credential (or verifiable presentation) by OP, it gets passed to the RS which verifies it (relying on OIDC key discovery!).
• DPOP mandated signing of DPoP Proof JWT by the client, it gets verified by RS based on public key inserted into verifiable credential (or verifiable presentation) by OP.

Unless I misunderstood something it sounds reasonable. Especially if we can use JWT based verifiable presentation incuding id credential and capability credential(s).

https://www.w3.org/TR/vc-data-model/#jwt-encoding

kid MAY be used if there are multiple keys associated with the issuer of the JWT. The key discovery is out of the scope of this specification. For example, the kid can refer to a key in a DID document, or can be the identifier of a key inside a JWKS.

Since VC spec leaves key discover as out of scope, we can simply point to OIDC spec as discovery mechanism for VC / VP proofs.

[elf-pavlik]

I believe latest draft addresses both stated concerns.