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

Support Client Configuration Endpoint #134

Closed
gobengo opened this issue Oct 9, 2015 · 7 comments
Closed

Support Client Configuration Endpoint #134

gobengo opened this issue Oct 9, 2015 · 7 comments
Assignees
Labels
Milestone

Comments

@gobengo
Copy link
Contributor

gobengo commented Oct 9, 2015

http://openid.net/specs/openid-connect-registration-1_0.html#ClientConfigurationEndpoint

oic.oic.Provider:registration_endpoint works great, and the ClientRegistrationResponse includes the 'registration_client_uri'. However, if I issue GET requests to that URI, I usually get a 400 Bad Request response code. It looks like this is because the GET request is treated the same as a (new) Client Registration Request.

@rohe Is this "Client Read Request" functionality something intentionally omitted? Or would you welcome contributions to implement it?

@rohe
Copy link
Collaborator

rohe commented Oct 14, 2015

9 okt 2015 kl. 20:58 skrev Benjamin Goering notifications@github.com:

http://openid.net/specs/openid-connect-registration-1_0.html#ClientConfigurationEndpoint

oic.oic.Provider:registration_endpoint works great, and the ClientRegistrationResponse includes the 'registration_client_uri'. However, if I issue GET requests to that URI, I usually get a 400 Bad Request response code. It looks like this is because the GET request is treated the same as a (new) Client Registration Request.

@rohe Is this ”Client Read Request" functionality something intentionally omitted?

Not intentionally omitted!

Or would you welcome contributions to implement it?

Yes ! :-)

— Roland
'Look, that's why there's rules, understand? So that you think before you break ’em.’ - Terry Pratchett

@gobengo
Copy link
Contributor Author

gobengo commented Oct 15, 2015

Thanks @rohe. I'll work toward a pull request that you and others can weigh in on.

@decentral1se decentral1se added this to the P2: SHOULD milestone Feb 21, 2017
@tpazderka tpazderka self-assigned this Dec 1, 2017
@tpazderka tpazderka added enhancement and removed bug labels Dec 1, 2017
@tpazderka
Copy link
Collaborator

We do have our own implementation of this, so I can give it a try.

@tpazderka tpazderka removed their assignment Dec 1, 2017
@tpazderka
Copy link
Collaborator

Eh, sorry. Misread the issue. I am not familiar with the usage of endpoints in this manner.

@tpazderka
Copy link
Collaborator

It looks like this cannot be done in the current state of the Endpoint class. Each endpoint is bound to one function. In order to get this to work, we would have to create a new Endpoint subclass that would be doing this. It would be then a question of configuration to distinguish between POST/GET on the same url and pointing to the correct endpoint.

@schlenk
Copy link
Collaborator

schlenk commented Dec 6, 2017

Isn't this implemented in the oic/extension/providers.py code:

https://github.com/OpenIDC/pyoidc/blob/a0dcac099c2b1adb0bd546080175d77c725bc48f/src/oic/extension/provider.py#L449

At least it looks pretty similar.

@tpazderka
Copy link
Collaborator

You are correct!

The only documented method in OIDC specifications is GET so I would definitely move that one to the generic class. The rest probably should remain in the extensions. We should enable easy override of the other methods for users.

I will give it a try later this week.

@tpazderka tpazderka self-assigned this Dec 11, 2017
tpazderka added a commit that referenced this issue Dec 11, 2017
tpazderka added a commit that referenced this issue Dec 11, 2017
andrewkrug pushed a commit to mozilla-iam/pyoidc that referenced this issue Jun 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants