Tight 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. In our case this is performed by
djangoldp_account(the RS) - DjangoLDP-Account implements a WebFinger endpoint on the user model which discovers the issuer for the account. Since this is part of the OIDC Discovery specification 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, 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 investigation
Activity
added needs investigation label
mentioned in issue #4 (closed)
This package should work as is, but it needs an adapted user model.
@balessan if we don't care about the maintenance of this package, maybe it would be easier/safer to merge it with djangoldp-account?
I think that we might care about the separation of the package later - since we might want to re-merge it with its parent django-oidc-provider?
When we implement
DPoPas far as I know we'll be the only serverside implementation of it existing (if I'm wrong about this please let me know !)
@calummackervoy : you're wrong, it looks like some servers already support it, as we can on the Solid test suite repository with the WebID Provider test suite checking the DPOP compliance.
Or do you mean the only django implementation ?
-
since we might want to re-merge it with its parent django-oidc-provider?
@calummackervoy I do not think it will ever happen :-)
-
@balessan I still think that separation will be good towards the goal of having users able to use federated djangoldp without djangoldp_account ?
mentioned in issue #2
mentioned in merge request djangoldp-account!89 (merged)