Django WebIDOIDC Provider issueshttps://git.startinblox.com/djangoldp-packages/django-webidoidc-provider/-/issues2022-05-17T16:20:51+02:00https://git.startinblox.com/djangoldp-packages/django-webidoidc-provider/-/issues/19Provider doesn't record consent on HDP2022-05-17T16:20:51+02:00Ghost UserProvider doesn't record consent on HDPPlaying the Gitea config I see there is an option to record consent. And it works but not on HDP provider.
I'm always required to agree to the authorization request at each access from the browser.Playing the Gitea config I see there is an option to record consent. And it works but not on HDP provider.
I'm always required to agree to the authorization request at each access from the browser.https://git.startinblox.com/djangoldp-packages/django-webidoidc-provider/-/issues/18Provider doesn't respect scope2021-08-03T19:17:35+02:00Ghost UserProvider doesn't respect scopeI configured a Gitea to authenticate users from the HD Paris OIDC provider. I need the email and username in order to make the autoregistration work seamlessly.
I configured the scopes `openid profile email` on both sides but when I arr...I configured a Gitea to authenticate users from the HD Paris OIDC provider. I need the email and username in order to make the autoregistration work seamlessly.
I configured the scopes `openid profile email` on both sides but when I arrive on the page for the consent, I see only `scopes=openid` in the authorize URL.https://git.startinblox.com/djangoldp-packages/django-webidoidc-provider/-/issues/13Documentation2021-08-03T19:32:33+02:00Calum MackervoyDocumentationIn our readme we point to the [django-oidc-provider](https://django-oidc-provider.readthedocs.io/en/latest/) documentation, but now this library has diverged quite a lot, I think we need our own?
To be specific
* [ ] settings (#8 )
* [ ...In our readme we point to the [django-oidc-provider](https://django-oidc-provider.readthedocs.io/en/latest/) documentation, but now this library has diverged quite a lot, I think we need our own?
To be specific
* [ ] settings (#8 )
* [ ] custom error codes (i.e. those introduced in !10 )
* [ ] Solid OIDC informationhttps://git.startinblox.com/djangoldp-packages/django-webidoidc-provider/-/issues/11DPOP Proof replay2021-02-25T16:54:13+01:00Ghost UserDPOP Proof replay@calummackervoy We need to implement this mecanism: https://tools.ietf.org/html/draft-fett-oauth-dpop-04#section-9.1@calummackervoy We need to implement this mecanism: https://tools.ietf.org/html/draft-fett-oauth-dpop-04#section-9.1https://git.startinblox.com/djangoldp-packages/django-webidoidc-provider/-/issues/10DPoP: Extending Client to store Client ID (Linked-Data Resource)2021-03-02T18:18:32+01:00Calum MackervoyDPoP: Extending Client to store Client ID (Linked-Data Resource)In the [Solid-OIDC Primer](https://solid.github.io/authentication-panel/solid-oidc-primer/#authorization-code-pkce-flow-step-18) the client-id given is a linked-data resource
Currently, the `Client` model stores an `id` (internal) and a...In the [Solid-OIDC Primer](https://solid.github.io/authentication-panel/solid-oidc-primer/#authorization-code-pkce-flow-step-18) the client-id given is a linked-data resource
Currently, the `Client` model stores an `id` (internal) and a `website` (homepage), neither of which are suitable for this purpose
We should extend the model, or possibly replace the internal client `id` with the linked-data resource format
This is non-blocking as we can store it in the website field in the short-term
...
Also required from the [Solid-OIDC Spec](https://solid.github.io/authentication-panel/solid-oidc-primer/#authorization-code-pkce-flow-step-7):
> If an app WebID is provided as the client id (see note above to see other options), we must fetch that app WebID to confirm its validity.
This will require work RS-side as well (djangoldp_account)
* `AuthorizeEndpoint.validate_params` should also [validate the redirect_uri matches the client ID](https://solid.github.io/authentication-panel/solid-oidc-primer/#authorization-code-pkce-flow-step-8)https://git.startinblox.com/djangoldp-packages/django-webidoidc-provider/-/issues/5Tight coupling with djangoldp_account2021-05-10T15:38:21+02:00Calum MackervoyTight coupling with djangoldp_account`djangoldp_account` implements some of the resource server endpoints, which `oidc_provider` depends on
Tasks (WIP):
* [ ] the OP [should perform the redirect](https://solid.github.io/authentication-panel/solid-oidc-primer/#authorization...`djangoldp_account` implements some of the resource server endpoints, which `oidc_provider` depends on
Tasks (WIP):
* [ ] the OP [should perform the redirect](https://solid.github.io/authentication-panel/solid-oidc-primer/#authorization-code-pkce-flow-step-11). In our case this is performed by `djangoldp_account` (the RS)
* [ ] DjangoLDP-Account [implements a WebFinger endpoint](https://git.startinblox.com/djangoldp-packages/djangoldp-account/blob/master/djangoldp_account/endpoints/webfinger.py#L22) on the user model which discovers the issuer for the account. Since this is part of the [OIDC Discovery specification](https://openid.net/specs/openid-connect-discovery-1_0.html#EmailSyntax) I think it belongs in the OP. Reading the code it looks like it was designed to be in the OP, but was taken out because it extends a [webfinger mechanism defined in DjangoLDP](https://git.startinblox.com/djangoldp-packages/djangoldp/blob/master/djangoldp/endpoints/webfinger.py), but I can't be sure. One thing I find really confusing about this is that django-oidc-provider says that it implements OpenID discovery, but doesn't seem to include a webfinger endpoint at all. Needs investigationhttps://git.startinblox.com/djangoldp-packages/django-webidoidc-provider/-/issues/3Unmaintained dependency: JWKest2021-03-15T19:23:09+01:00Calum MackervoyUnmaintained dependency: JWKestA library we are using ([JWKest](https://github.com/IdentityPython/pyjwkest)) is not being actively maintained. This is a dependency inherited from Django-OIDC-ProviderA library we are using ([JWKest](https://github.com/IdentityPython/pyjwkest)) is not being actively maintained. This is a dependency inherited from Django-OIDC-Providerhttps://git.startinblox.com/djangoldp-packages/django-webidoidc-provider/-/issues/2Django-Solid-OIDC-Provider2021-03-22T15:43:50+01:00Calum MackervoyDjango-Solid-OIDC-ProviderEDIT: this issue originally focussed on consolidating parts of DjangoLDP-Account's functionality into Django-WebID-OIDC-Provider. This I think is covered by #5 so now the scope of the issue can be relating to the changes in the [Solid OI...EDIT: this issue originally focussed on consolidating parts of DjangoLDP-Account's functionality into Django-WebID-OIDC-Provider. This I think is covered by #5 so now the scope of the issue can be relating to the changes in the [Solid OIDC specification](https://solid.github.io/authentication-panel/solid-oidc/) from the older [WebID OIDC specification](https://github.com/solid/webid-oidc-spec)
See #6 for background and a comparison of the two specifications
Without further ado here are the tasks I think will be involved in the upgrade:
* [x] DPoP (OP-side #1 , RS-side https://git.startinblox.com/djangoldp-packages/djangoldp-account/issues/70)
* [ ] Client identifiers as URI (#10 )
* [x] `code_challenge_methods_supported` key should be returned in `ProviderInfoView` response (optional)
* [ ] Implicit grant type support dropped for [security reasons](https://oauth.net/2/grant-types/implicit/)
* [user's webid is stored on client](https://solid.github.io/authentication-panel/solid-oidc-primer/#authorization-code-pkce-flow-step-10), but since we store the `user`, who _should_ have a webid, this may be implicit
* [access token fields](https://solid.github.io/authentication-panel/solid-oidc-primer/#authorization-code-pkce-flow-step-18). Being covered in the work on DPoP
* `webid` in id_token. Being covered in the work on DPoP
* [x] [MUST advertise solid-oidc conformance in OIDC discovery](https://solid.github.io/authentication-panel/solid-oidc/#discovery)
* included missing RS-side steps in https://git.startinblox.com/djangoldp-packages/djangoldp-account/issues/70