Closed jaxoncreed closed 4 years ago
DPoP Draft Proposal: https://tools.ietf.org/html/draft-fett-oauth-dpop Cavage Signatures Draft: https://tools.ietf.org/html/draft-cavage-http-signatures
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).
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:
id_token
by OP, which only goes and gets verified by the client (never goes to RS)verifiable credential
(or verifiable presentation
) by OP, it gets passed to the RS which verifies it (relying on OIDC key discovery!).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.
I believe latest draft addresses both stated concerns.
Notes from Justin Richer:
The current flow the PoP tokens can be kept with these changes: