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