What is the reason sender constrained verification is pushed on to Resource Server instead of introspection API doing it?

[Arjun Balla]

Hi Brian

I just realized that, you are the author of the spec and this may be a stupid question but I would ask anyway.

I couldn’t find a better forum to reach you. My apologies, if this is not the forum for this question.

‌

access_token as Reference Tokens

In case of CBAT and DPoP, Resource Server needs to compare cnf.x5t#S256 in response of introspection API with computed x5t#S256 of certificate it received.

access_token as JWT

In case of CBAT and DPoP, Resource Server needs to compare cnf.jkt claim in access_token or in response of introspection API with computed base64urlencode(sha256(jwk)) it received.

I think it is responsibility of Authorization Server to do this validation.

Also, we can not trust Resource Server to implement the specification perfectly.

‌

I understand that specification is not written as below but just for discussion, why this was not considered?

‌

In case of CBAT, Resource Server can pass the certificate it received to introspection API and it can validate. I understand that, Resource Server does not have Client's Private Key and hence there is no mtls between Resource Server and Authorization server but I dont see any security risk.

In case of DPoP, Resource Server can pass the DPoP header it received to introspection API and it can validate.

If any Authorization Server wants to implement the introspection API this way do you see any problem?

Can you please clarify?

‌

[Brian Campbell]

It’s not a stupid question but not something that’s easy to succinctly answer. And yeah, this isn’t really the forum either. But I’ll try.

Quite a bit of additional context info of the original request would need to be provided to the introspection API for it to do all the validation of the proof correctly. There’d be more to it than just passing the DPoP header or the client certificate. There were lots of considerations that went in to how the specifications were written, including what you’ve described. But treating the access token confirmation data and associated validation consistently for both self-contained JWT access tokens (where there’s likely no callback to the AS) and introspected access tokens was the approach that came out of the working group consensus process. And I do think it’s the most appropriate and straightforward design.

You could do an introspection type API the way you described but there are likely quite a few non-obvious details you’d need to be careful with.

‌

[Arjun Balla]

Thanks for the response.

Because you said this is not the forum, I dont want to further drag the discussion here.

What I understand from your answer is that the group did looked into lot of other approaches including the one I mentioned and considered the current approach as clean and straightforward. I have no doubt that the current approach is the right one and I trust you and other specification writers more than myself as you guys have more knowledgable and experienced than me.

I still do not understand the different aspects went into rejecting introspection API approach. You did mention that you can not explain it here in couple of lines. From your busy schedule if you can take some time and write a blog post I would greatly appreciate.

‌

Is there a forum where I can ask these kind of questions? If yes, can you point me to that?

‌

Again, thank you very much for answering the question.

‌

‌

‌