Repository navigation
Hosting Client ID Document on Solid Storage #95
Description
Ac currently defined Client ID Document MUST use normative JSON-LD @context, so it has to be compacted with it. Solid Storage doesn't guarantee that compaction is being preserved for RDF-Sources.
We need to double-check if Solid Storage could guarantee that. At the same time, we should gather feedback from existing implementation on how important that feature is for them. Most (all?) plain OIDC implementation doesn't support client registrations published externally as a resource on the web. Fetching them needs to be implemented as a custom future, possibly this extra functionality could take care of parsing RDF and compacting it with provided JSON-LD @context. Personally, I find it more practical to let consumers take care of compacting with a @context they rely on.
Activity
elf-pavlik commentedon Sep 17, 2022
There is a relevant conversation in solid/notifications#105
I would also like to reference example of Metadata with RP's Entity Configuration from OpenID Connect Federation 1.0 - draft 22
{ "iss": "https://openid.sunet.se", "sub": "https://openid.sunet.se", "iat": 1516239022, "exp": 1516298022, "metadata": { "openid_relying_party": { "application_type": "web", "redirect_uris": [ "https://openid.sunet.se/rp/callback" ], "organization_name": "SUNET", "logo_uri": "https://www.sunet.se/sunet/images/32x32.png", "grant_types": [ "authorization_code", "implicit" ], "signed_jwks_uri": "https://openid.sunet.se/rp/jwks.jose" } }, "jwks": { "keys": [ { "alg": "RS256", "e": "AQAB", "key_ops": [ "verify" ], "kid": "key1", "kty": "RSA", "n": "pnXBOusEANuug6ewezb9J_...", "use": "sig" } ] }, "authority_hints": [ "https://edugain.org/federation" ] }Which is also referenced from Self-Issued OpenID Provider v2: 6. Discovery and Registration
If we would want to use something directly from OIDC pool of specifications, we should probably use this format.
Given that we already diverge from the existing spec, and existing OP implementations need to be extended to support Solid-OIDC Client ID Document. I think we should reconsider removing requirements which are not guaranteed for a RDF Source hosted in Solid Storage.
elf-pavlik commentedon Sep 17, 2022
@dteleguin I recall that you might have been implementing Solid-OIDC in Keycloak, if that's the case your implementation experience with handling Client ID documents would be very helpful, especially if handing them as RDF would make a significant impact on implementation. For example, getting JSON-LD without any specific
@contextor structure and for example, simply compacting it with the@contextcurrently provided by the Solid-OIDC spec on the consumer side. /cc @justinwbelf-pavlik commentedon Sep 17, 2022
It seems that CSS already supports Client IDs as plain RDF Sources https://github.com/CommunitySolidServer/CommunitySolidServer/blob/d2908480960b9708460ad71c010ea11e86497968/src/identity/storage/WebIdAdapterFactory.ts#L72
I asked for confirmation, but my current take is that this would not impact CSS OIDC Provider implementation at all.
elf-pavlik commentedon Oct 8, 2022
Thinking about #199, I'd like to consider another option, related to #26
If we define
solidclaim, we could use it in the following way:Where we provide the WebID of the end-user and the WebID of the application. This way
client_idwould be an IRI resolving toentity-statement+jwtand wouldn't be used to identify the application outside of the OIDC flow.We still would need to define how the application includes its WebID in its Entity Statement.
EDIT: we should also coordinate discussion here with solid/specification#463