Authenticating Clients about authentication-panel HOT 3 CLOSED

Regarding aspect of Client authenticating to Resource Server. Depending on which identifier RS needs to authenticate we seem to have different reliance on Authorization Server. If client only needs to identify client by the key it holds and to which the token stays bound, RS can directly verify possession of that key. If we rely on some identifier like redirect_uri, RS can't directly verify it and needs to rely on Authorization Server using it in Authorization Code grant.

Requirement on which identity client has to prove to Resource Server also seems related to outcomes of Authentication panel. If access token includes (by value or reference) all the client authorization information that Resource Server should apply to the client using that access token, we can think of those authorization as 'semantic scopes', Resource Server doesn't need to verify any other client identity and use it to discover authorization details it should apply to the client.

from authentication-panel.

If we rely on some identifier like redirect_uri, RS can't directly verify it and needs to rely on Authorization Server using it in Authorization Code grant.

Unless the RS requires a token that it issues itself. As you mentioned in today's panels, that could be an option in the rare case that the RS wants to identify the client.

from authentication-panel.

Yes, precisely some AS would still issue the token and RS would need to rely on that AS verifying redirect_url, just it would be AS designated by a user with acl:Control and not one associated with any other user with some other mode of access.

from authentication-panel.