Aaron Coburn

> the links should be updated to -08 as well The Solid-OIDC specification does not refer to a _particular_ DPoP draft version. Unless the section numbering has changed (it as...

> It is correct that we need to somehow indicate DPoP requirement The DPoP requirement is a requirement on the Server. It is indicated via the .well-known/openid-configuration metadata. A client...

Effectively, we are representing a triple pattern in normative text. This is something SPARQL 1.1 defines, so we should add a reference to the relevant section from the SPARQL spec...

This is very simple: Solid-OIDC is concerned only with Authentication. It does this by defining an _ID Token_: a token that identifies who an agent is. (Note that this is...

The scope of Solid-OIDC is Authentication. It defines how an ID Token is formatted for use with Solid. Solid-OIDC very purposefully says nothing about access tokens. Any access token produced...

Just want to note here that this could be an interesting _optional_ feature. Requiring support, however, would be hugely problematic for anyone implementing an identity broker, which is important for...

Is there anything stopping an identity provider from implementing the [openid-connect-prompt-create](https://openid.net/specs/openid-connect-prompt-create-1_0.html) draft today? I certainly don't see any reason that an IdP couldn't. Of course many IdPs will choose not...

> After all, the current draft is already so complex that it is impossible to make most popular OIDC providers compliant without some serious backend development By that argument, adding...

ClientIDs are defined specifically for Solid-OIDC. A server that doesn't implement Solid-OIDC would not, _ipso facto_, implement a Solid-OIDC specific feature. I am very wary of adding additional requirements to...

The Solid-OIDC draft currently adds four requirements above vanilla OIDC: * `webid` claim -- this is specific to the Solid ecosystem. Without it, Solid apps and servers do not have...