consider support for OIDC self-issuer

[zenomt]

as discussed on one of the calls and in solid/authentication-panel#2 (comment), support for the OIDC magic issuer https://self-issued.me with a public key in the webid profile (same as WebID-TLS) would have several benefits:

• marginally easier to set up a bot identity on an ordinary static web server vs creating a .well-known/openid-configuration and a jwks file (plus saving two more serialized HTTP transactions to fetch them)
• enables on-device authentication (for example, a native app on a mobile device) using the self-issuer workflow envisioned by OIDC

[jaxoncreed]

The self-issued identity for oidc makes a lot of sense for Solid, though there needs to be one tweak.

The identity in the self-issued flow is assumed to be the device itself (or whatever has the private key). This is why the jwk for the device is embedded directly into the token (https://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedValidation). But in Solid, your identity is your WebID, and therefore the WebID must be correlated with the self-issued token.

Instead, the jwk should be embedded in the WebID via the cert:key, similar to the way the public key was provided under WebID-TLS

This might mean using https://self-issued.me more as an inspiration rather than fully using that implementation, but I think this will be a fine replacement for WebID-TLS as it is more in line with the other authentication flow and is more user-friendly.

[zenomt]

Instead, the jwk should be embedded in the WebID via the cert:key, similar to the way the public key was provided under WebID-TLS

exactly this is specified in my auth proposal (see step 8 of WebID-OIDC operation).

[zenomt]

Instead, the jwk should be embedded in the WebID

exactly this is specified in my auth proposal

to clarify and be precise, my auth proposal actually specifies that the jwk is embedded in the id_token so that it's compatible with OIDC self-issuing, but that the public key is also in the webid.

an implementation could either verify the id_token signature from its embedded public key and confirm that the public key also appears in the webid, or it could verify the id_token's signature against the public key(s) listed in the webid and ignore the public key in the id_token.

i think it's valuable to keep the public key in the id_token in the self-issued case for compatibility with the semantics of OIDC's magic issuer https://self-issued.me.

[dmitrizagidulin]

As another reference point to this discussion, I'd like to add the Using OpenID Connect Self-Issued to achieve DID Auth paper from the Rebooting Web of Trust 8 conference.
Although it deals with DID-based authentication, the workflow would be almost identical for WebID authentication. This is the approach being taken by a wide swath of the Decentralized Identity community (and note that one of the paper coauthors is Mike Jones, who is the coauthor of the OpenID Connect spec itself).

[elf-pavlik]

To my understanding to resolve this issue we need a clear proposal for how to add that self-issued OP to User's WebID Profile. Since we use solid:oidcIssuer for regular OPs, I could add PR with finding proposing new predicate eg. solid:oidcSelfIssuedJwk.

@dmitrizagidulin regarding that OIDC DID Auth paper, I think it would help to move forward in https://github.com/solid/identity-panel/issues/1 with discussion how WebID could get aligned with DID. After that we could revise all requirements on WebID Profile including the one discussed here.

[jaxoncreed]

I could add PR with finding proposing new predicate eg. solid:oidcSelfIssuedJwk.

+1 on this specifically

[zenomt]

solid:oidcSelfIssuedJwk

-1 on this specifically. i think this should be handled with already-existing predicates in the webid document: cert:key and solid:oidcIssuer:

<#me>
      solid:oidcIssuer <https://self-issued.me>; # maybe this could be optional
      cert:key [
          a cert:RSAPublicKey;
          cert:exponent 65537;
          cert:modulus "EBED6EB8...459"^^xsd:hexBinary
      ] .

an id_token that looks self-issued and that is signed by one of the webid's cert:keys should be sufficient.

[elf-pavlik]

<#me>
      solid:oidcIssuer <https://self-issued.me> . # maybe this could be optional

I don't see what putting it in the profile supposed to mean. Also any software doing solid:oidcIssuer discovery would need to know to treat it differently if it has <https://self-issued.me> on object position.

<#me>
      cert:key [
          a cert:RSAPublicKey;
          cert:exponent 65537;
          cert:modulus "EBED6EB8...459"^^xsd:hexBinary
      ] .

If cert ontology supports both RS256 and ES256 I see no problem to use it for describing the key instead of relying on JWK format.

https://www.w3.org/ns/auth/cert#key

key - relates an agent to a key - most often the public key.

I guess we could just rely on that for verifying key used for self-issued OIDC.

---

Looking at paper suggested by @dmitrizagidulin https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/1801e8f9d4af6f666e50266303e62eadefefa544/draft-documents/did-auth-oidc.md#did-validation

5. Verify that the self-issued key used to sign the response (specified in the sub_jwk claim) is present in the authentication attribute of the DID Document and is not expired or revoked. The key specified in the DID Document can be in various formats and they must be converted to a common format to compare. This conversion is out of scope of this document.

If identity-panel should take care of solid/authentication-panel#16 and propose how to align WebID with DID, I think we should just add requirement of associating public key used for OIDC self-issuer to get addressed as part of that effort.

[zenomt]

I don't see what putting it in the profile supposed to mean.

putting it in the profile means that when an id_token is received with an iss of https://self-issued.me, that iss is an expected and allowed issuer.

since demonstrating control of the public key is sufficient (with a signature that matches), i wouldn't object to dropping solid:oidcIssuer <https://self-issued.me>, although i think it makes a stronger statement about the intent of the Agent coming from the other direction (that is, knowing from looking at the webid that you might expect to see a self-issued id_token someday).

[jaxoncreed]

i think it makes a stronger statement about the intent of the Agent coming from the other direction (that is, knowing from looking at the webid that you might expect to see a self-issued id_token someday).

POSSIBLE OPTION 1:

Just say all clients MUST be aware of the self-issued flow. This might be the simplest

POSSIBLE OPTION 2:

Alternatively, we could make our own self issued site like https://self-issued.solidproject.org that would simply return oidc-compatible information dynamically made for the specific WebID. Your profile could contain:

<#me>
      solid:oidcIssuer <https://self-issued.solidproject.org/jackson.solid.community/profile/card> .

And when calling https://self-issued.solidproject.org/jackson.solid.community/profile/card/.well-known/openid-configuration and https://self-issued.solidproject.org/jackson.solid.community/profile/card/jwks it would simply dereference the WebID and return the provides cert as a JWKS.

The downside is the URL could get pretty messy if we allow different protocols, and it's already pretty messy.

It also has the downside of depending on a centralized party to take care of clients that aren't award of

POSSIBLE OPTION 3:

People using a self-issued id could host their own server that does the same thing outlined above. But, at that point, you're essentially running an IDP. Though, it would only be used for clients that don't understand the self-issued flow.

[elf-pavlik]

I see a new draft for Self-issued OpenID Provider v2

https://openid.net/specs/openid-connect-self-issued-v2-1_0.html#name-relationship-with-section-7

This specification extends Section 7 of [OpenID.Core] Self-Issued OpenID Provider in the following ways:

• Added support for Decentralized Identifiers defined in [DID-Core] as Cryptographically Verifiable Identifiers in addition to the JWK thumbprint defined in Self-Issued OP v2. See Section 8.2.2.
• Added support for Cross-Device Self-Issued OP model. See Section 5.
• Extended Relying Party Registration mechanisms to support pre-registration and dynamic registration for not-pre-registered RPs. See Section 9.
• Added support for Dynamic Self-Issued OpenID Provider Discovery. See Section 8.2.
• Added support for claimed URLs (universal links, app links) in addition to the custom URL schemas as Self-Issued OP authorization_endpoint. See Section 8.2.1.
• Allows use of any OpenID Connect flow for Self-Issued OPs and Dynamic Client Registration
  Note that while this specification extends the original Section 7 of [OpenID.Core] Self-Issued OpenID Provider, some sections of it could be applicable more generally to the entire OpenID Connect Core specification.