Hosting Client ID Document on Solid Storage

[elf-pavlik]

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.

[elf-pavlik]

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]

@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 @context or structure and for example, simply compacting it with the @context currently provided by the Solid-OIDC spec on the consumer side. /cc @justinwb

[elf-pavlik]

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]

Thinking about #199, I'd like to consider another option, related to #26

If we define solid claim, we could use it in the following way:

"solid": {
  "user": "https://alice.example"
  "application": "https://projectron.example"
}

Where we provide the WebID of the end-user and the WebID of the application. This way client_id would be an IRI resolving to entity-statement+jwt and 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