One take away I had from the meeting today, and form the mail list, is the concern of doing asymmetric crypto on API calls. How about if we use the Client's public key to encrypt a symmetric key and pass that back to the Client in the token request response?
EG: In response to the token request, the AS additionally returns a derived symmetric key (SK) encrypted in a JWE using the Client's public key from the DPoP Proof. The SK = hash( salt, R ) R and the salt version V are included in the access token The AS and the RS share salts with versions. The Client decrypts the JWE and now has a symmetric key to sign a Symmetric DPoP Proof. The RS take R and V to calculate SK, and verify the signature of the Symmetric DPoP Here is an updated flow: +--------+ +---------------+ | |--(A)-- Token Request ------------------->| | | Client | (DPoP Proof) | Authorization | | | | Server | | |<-(B)-- DPoP-bound Access Token ----------| | | | (token_type=DPoP) +---------------+ | | PoP Refresh Token for public clients | | Symmetric Key JWE Client decrypts DPoP Symmetric Key | | | | +---------------+ | |--(C)-- DPoP-bound Access Token --------->| | | | (Symmetric DPoP Proof) | Resource | | | | Server | | |<-(D)-- Protected Resource ---------------| | | | +---------------+ +--------+
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
