Proposal: support Self-Issued OpenID Providers as issuers for WebIDs

[zenomt]

a Self-Issued OpenID Provider is a self-hosted OIDC Provider that issues self-signed ID tokens. such a self-signed ID token includes a public key in its sub_jwk claim, with which the token is signed. a self-signed ID token is identified as such with a special reserved issuer of "https://self-issued.me".

Proposal: extend the webid-oidc-spec to allow this case by:

• recognizing that ID tokens can be self-issued, and bypassing OIDC Issuer Discovery and using the public key in the ID token's sub_jwk claim to validate the signature when the token is self-issued (according to the iss claim);

• requiring (for this case) that the webid claim is used to name the WebID, because the sub claim is reserved for the "thumbprint" of the sub_jwk;

• reiterating in Authorized OIDC Issuer Discovery that the solid:oidcIssuer predicate applies in this case and must exactly match the iss of the ID token, which is the special reserved URI <https://self-issued.me>; and

• validating that the WebID has a http://www.w3.org/ns/auth/cert#key predicate whose type and key parameter statements (exponent and modulus for RSA, currently the only key type supported by Self-Issued OPs) match those of the sub_jwk.

TL;DR: ID tokens can be self-signed. validate self-signatures, confirm WebID lists the same public key, and WebID says its issuer is the self-issued OP.

Use case: a bot or other automatic agent can have a WebID. allowing the use of self-issued ID tokens with WebID-OIDC can simplify these agents and their deployments by not requiring a stub implementation of an OIDC Provider with at least its configuration and jwks endpoints just to verify ID token signatures. all that's required is hosting a single static profile document on an ordinary web server for the agent to have a WebID.

[jaxoncreed]

+1. We need to ensure an implementation that can allow bots to authenticate.

[jaxoncreed]

Had a talk with @dmitrizagidulin and he thinks this has some great implications for DiD implementations. We think there are more considerations to do before integrating it into the spec, so maybe he can talk about them here.

[zenomt]

@jaxoncreed @dmitrizagidulin

We think there are more considerations to do before integrating it into the spec, so maybe he can talk about them here.

ping?

[zenomt]

also as i mentioned in #30 (comment) the spec should explicitly allow multiple solid:oidcIssuers, for the command-line tool case. that way i can have a normal OIDC Provider that i can log in with normally in my browser, and the self-issued provider for use with command-line tools. my webid https://zenomt.zenomt.com/card.ttl#me is doing this. an inline example for posterity:

@prefix cert:  <http://www.w3.org/ns/auth/cert#> .
@prefix solid: <http://www.w3.org/ns/solid/terms#> .
@prefix xsd:   <http://www.w3.org/2001/XMLSchema#> .

<#me>
    solid:oidcIssuer
        <https://oidc.example>,   # my regular OP
        <https://self-issued.me>; # for command-line tools

    cert:key [
        a cert:RSAPublicKey;
        cert:exponent 65537;
        cert:modulus "D7B6DF...A5EC"^^xsd:hexBinary # modulus abbreviated for clarity
    ].

[zenomt]

as i mentioned in nodeSolidServer/oidc-auth-manager#45 it appears that NSS today doesn't work correctly if there are multiple solid:oidcIssuers.