Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove unnecessary client_uri parameter #13

Open
selfissued opened this issue Oct 30, 2022 · 4 comments
Open

Remove unnecessary client_uri parameter #13

selfissued opened this issue Oct 30, 2022 · 4 comments

Comments

@selfissued
Copy link

In Automatic Client Registration, there's no need for the client_uri parameter because this information is already carried in the client_id parameter. When an authorization server receives a request with a client_id value that is an https URL, it retrieves the contents of the URL to obtain the client data.

Note that the authorization server can tell that the resource contains data about the client because the response uses the media type application/entity-statement+jwt.

Therefore, please remove the unnecessary client_uri parameter. Thanks.

@tplooker
Copy link
Member

Just to clarify where would you like to remove this from, the intent of the draft (which I suspect is unclear) is when a client is making an authorization or token request to an AS and is wishing to indicate it is discoverable, that it set its client_id == its client_uri, the value of the client_uri for the client is also present in its resolved metadata.

@selfissued
Copy link
Author

I understand the intent. My point is that you can already tell that the client is publishing its client information for retrieval by the AS by sending an https-valued client_id without having this parameter. Having the application/entity-statement+jwt media type in the response is a double-check on that.

@aaronpk
Copy link

aaronpk commented Nov 9, 2022

This does bring up the question of how you would indicate a resolvable client_id that is using a scheme other than https. Tho I personally tend to agree that using client_id for this rather than defining a new parameter makes sense.

@tplooker
Copy link
Member

@aaronpk please review the latest draft where we have moved from client_discovery to a parameter that describes how to interpret the client_id, which I believe creates the required extensibility point for clients that want to identify with an AS using a non https based identifier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants