solid / data-interoperability-panel

Repository for the Solid Data Interoperability Panel
MIT License
51 stars 19 forks source link

Add contexts and agent profiles for json-ld #233

Closed justinwb closed 2 years ago

justinwb commented 2 years ago

Created a sub-folder to house json-ld contexts since there will be more. Renamed to application-profile context and added another for social agent profile.

elf-pavlik commented 2 years ago

@justinwb could you please paste in your initial comment an example of document using this context together with Solid-OIDC one?

justinwb commented 2 years ago

@justinwb could you please paste in your initial comment an example of document using this context together with Solid-OIDC one?

@elf-pavlik I think you mean the thread from this PR? https://github.com/solid/data-interoperability-panel/pull/231

elf-pavlik commented 2 years ago

I think examples of using both contexts would be helpful. I assume that you went with snake case to match solid-oidc context.

justinwb commented 2 years ago

I think examples of using both contexts would be helpful. I assume that you went with snake case to match solid-oidc context.

Switched to camelCase for social agent profile. Not sure if we should do the same for application profile given the cross-pollination with the client identifier doc from solid-oidc which doesn't use it.

acoburn commented 2 years ago

I'm much happier with the camelCase format, thanks!

most json-ld that I've seen uses this style, including solid-oidc context

To be clear, solid-oidc uses the underscore style for the simple reason that it aims to align with https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata

justinwb commented 2 years ago

To be clear, solid-oidc uses the underscore style for the simple reason that it aims to align with https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata

@acoburn feels like it may be worth leaving the interop application context with the same style for the same reason since they'd be interspersed. will use camelCase on the rest 🙂

@acoburn @elf-pavlik While you're both here - it'd be great align on a best practice for a client id document incorporating both contexts. Here's what I've been doing for the time being:

  {
    "@context": [
        "https://www.w3.org/ns/solid/oidc-context.jsonld",
        "https://solid.github.io/data-interoperability-panel/specification/interop-application.jsonld"
    ],
    "client_id": "https://projectron.example/id",
    "client_name": "Projectron",
    "redirect_uris": [ "https://projectron.example/redirect" ],
    "post_logout_redirect_uris": [ "https://projectron.example/logout" ],
    "client_uri": "https://projectron.example/",
    "logo_uri": "https://projectron.example/logo.png",
    "tos_uri": "https://projectron.example/tos.html",
    "scope": "openid offline_access profile",
    "grant_types": [ "refresh_token", "authorization_code" ],
    "response_types": [ "code" ],
    "default_max_age": 3600,
    "require_auth_time": true,
    "application_description": "Best project management ever",
    "application_author": "https://acme.example/id",
    "has_access_need_group": [
      "https://projectron.example/access#group1",
      "https://projectron.example/access#group2" 
    ]
  }

Example live on JSON-LD playground

acoburn commented 2 years ago

Looks good!

Only (minor) comment is to include webid in the scope field

justinwb commented 2 years ago

Looks good!

Only (minor) comment is to include webid in the scope field

Ah great catch. I actually had to remove that from my local instance because I was getting rejections from CSS' IDP if I provided it (although it proceeds to issue tokens with it). Good reminder to file an issue for it!