I do love "ash" as a claim name but (as DPoP co-author and a DE on the JWT Claims registry) I'd strongly suggest that the binding be done the other way around. Basically just say that the AS binds the auth_session value to the the public key from the DPoP proof and checks the binding whenever the client sends the auth_session. Binding that way is simpler (from the spec perspective anyway) and provides more protections. It's also how most of the binding in DPoP works ("ath" is kind of an outlier and provides somewhat questionable value).
I do love "ash" as a claim name but (as DPoP co-author and a DE on the JWT Claims registry) I'd strongly suggest that the binding be done the other way around. Basically just say that the AS binds the auth_session value to the the public key from the DPoP proof and checks the binding whenever the client sends the auth_session. Binding that way is simpler (from the spec perspective anyway) and provides more protections. It's also how most of the binding in DPoP works ("ath" is kind of an outlier and provides somewhat questionable value).
https://www.ietf.org/archive/id/draft-parecki-oauth-first-party-apps-00.html#name-auth-session-dpop-binding https://www.ietf.org/archive/id/draft-parecki-oauth-first-party-apps-00.html#name-json-web-token-claims-regis