You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
OIDC issuer should return metadata regarding its identity #206
Hi.
I have been reading the Solid-OIDC and Solid-OIDC Primer specifications and I don't find any information regarding the solid:oidcIssuer information that should be publicly available.
I think it would make sense to specify that a request made to the solid:oidcIssuer URI should return information on the identity of the issuer, e.g, the entity responsible for the domain, the entity responsible for hosting, contact information, privacy policy, terms & conditions, what data is necessary to create a WebID (email account,...) and so on.
Is there a particular reason you need OAuth2/OpenID Connect terms explicitly defined as IRIs?
All entities involved in the Solid ecosystem, including identity providers, should provide at least basic information regarding their identity and contact information if they want to be compliant with data protection regulations. While is not the job of the Solid specs to describe/enforce this, at least a mention to it (maybe in the Privacy Considerations section of the specs?) should be made.
The issuer entity already has a URI. This is encoded as the iss claim in an ID Token and as the issuer property in the OpenID Metadata resource. From that URI, an OAuth2/OpenID client can discover additional data, such as the terms of use, contact information, privacy policy, etc, as per normal OIDC discovery (i.e. append .well-known/openid-configuration)
My earlier question was more centered around why expressing (for example) grant_types_supported or subject_types_supported as IRIs would be required?
Activity
elf-pavlik commentedon Oct 31, 2022
OIDC defines OP metadata in https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata
besteves4 commentedon Nov 1, 2022
Thanks for the reply @elf-pavlik
Is there a direct mapping between the terms in OP metadata spec and the ones in the Solid OIDC vocab?
I can guess a few, but it would be nice to have this mapping explicitly written, for instance in the Appendix A of the Solid-OIDC spec.
acoburn commentedon Nov 1, 2022
Only partially, and there, the purpose was constrained by a need to represent a client identifier document as JSON-LD.
The discussion related to #199 (using the OpenID Federation specification) would potentially remove the need for this JSON-LD mapping entirely.
Is there a particular reason you need OAuth2/OpenID Connect terms explicitly defined as IRIs?
besteves4 commentedon Nov 2, 2022
All entities involved in the Solid ecosystem, including identity providers, should provide at least basic information regarding their identity and contact information if they want to be compliant with data protection regulations. While is not the job of the Solid specs to describe/enforce this, at least a mention to it (maybe in the Privacy Considerations section of the specs?) should be made.
acoburn commentedon Nov 2, 2022
The issuer entity already has a URI. This is encoded as the
issclaim in an ID Token and as theissuerproperty in the OpenID Metadata resource. From that URI, an OAuth2/OpenID client can discover additional data, such as the terms of use, contact information, privacy policy, etc, as per normal OIDC discovery (i.e. append.well-known/openid-configuration)My earlier question was more centered around why expressing (for example)
grant_types_supportedorsubject_types_supportedas IRIs would be required?