Consider draft-parecki-oauth-client-id-metadata-document for input

[jeswr]

From @ThisIsMissEm on https://matrix.to/#/!LCtvHcfpDwWNfvmsEd:matrix.org/$LocW3byKZVVhwSCOfiD1UrdWJTOj1nUp_Z2QDidTcek?via=matrix.org&via=gitter.im&via=attendees.fosdem.org

I'm not sure where Solid ended up with on the notion of public client ID metadata documents, but Aaron Parecki and myself have lifted those up to an official IETF draft, and that document is now at the call for adoption phase: https://mailarchive.ietf.org/arch/msg/oauth/cc_oOMH2UpCowuM9MAL_61jTpxw/

[elf-pavlik]

@ThisIsMissEm signaled it before in

• IETF I-D for Client Identifiers as URIs solid/solid-oidc#237

Mentioned OIDC Federation was very lightly explored in

• Reconsider Client Identifiers in light of OpenID Federation Entities solid/solid-oidc#207
• Why does Client configuration data have to be JSON-LD serialized?  solid/solid-oidc#199 (I believe Kristina works on OIDC4VP)
• Adjust the primer towards OIDC Federation solid/solid-oidc#208

@acoburn may have even more relevant background

[elf-pavlik]

From what I remember, special requrement for JSON-LD with specific @context was causing some friction with publishing those client id documents on solid storage. Looking at suggested draft

https://www.ietf.org/archive/id/draft-parecki-oauth-client-id-metadata-document-03.html#name-client-metadata

The client metadata document MAY define additional properties in the response. The client metadata document MAY also be served with more specific content types as long as the response is JSON and conforms to application/+json

I understand that Soild-OIDC documents would still be valid but publishing them in Solid (possibly LWS) storage would still be problematic. OIDC Federation uses .well-known indirection which has it's own issues but at the same time has potential to publish that metadata in a dedicated location.

Today I also created #39, my brain might be playing tricks on me but this approach could possibly also provide a way to separate publishing plain JSON oidc metadata and RDF graph using content negotiation. This could possibly address mentioned friction in a different way.
Another place relying on Client ID Documents - https://solid.github.io/data-interoperability-panel/specification/#app

• Incorporate profile requirements from solid-oidc for Social Agents and Applications. solid/data-interoperability-panel#210

It would be really nice to be able to simply work with RDF everywhere except purely OIDC specific areas.

[ThisIsMissEm]

Yeah, typically Client ID Metadata Documents don't include @context and aren't served as JSON-LD, however, we wanted to allow backwards compatibility with the Solid-OIDC spec, so permitted additional properties in the response and allowed additional content-types outside of application/json

We're yet to define any specific requirements on the path component, but are considering requiring the path component end with .json or oauth-client-metadata.json, but I don't think we're considering well-known URIs: oauth-wg/draft-ietf-oauth-client-id-metadata-document#38

[elf-pavlik]

If LWS plans to use that draft it would be good to chime in on that issue. Personally I think Client ID URL should remain opaque and no magic strings should be required. If .well-known/ is used then it's a different story since it already works based on registered magic strings.

EDIT: this whole .well-known indirection actually makes it look more like https://openid.net/specs/openid-connect-federation-1_0-29.html#section-6

[acoburn]

The Security Considerations section of the OpenID Connect authentication suite specifically mentions Client Id Metadata Documents and where validation happens during the authentication flow (it is the responsibility of the OpenID Provider). OpenID Federation is also mentioned in this context.

In both cases, we cannot normatively reference draft spec documents, but we can mention them in a non-normative section, which seems like the best way to bring both of these efforts into LWS.

Given that, I believe this issue can be closed.

[elf-pavlik]

I plan to open an issue related to https://w3c.github.io/lws-protocol/lws10-authn-ssi-cid/ and client authentication, both on User AS and Resource AS side https://elf-pavlik.github.io/lws-auth/view/oidc/?dynamic=sequence

I see no problem with closing this issue, but I will probably still drop a link here once I have the other issue ready.