---
# System prepended metadata

title: 2021-05-24 Authorization Panel

---

# 2021-05-24 Authorization Panel

## Agenda

* [Define JSON-LD context for use with client identifiers #165](https://github.com/solid/authentication-panel/pull/165)
* Solid-OIDC in non-browser contexts

## Present

* Aaron Coburn
* elf Pavlik
* Henry Story
* Matthias Evering (ewingson)
* Martynas Jusevičius

## Minutes

### JSON-LD context

For client id resources, should the JSON-LD `@context` always be present to conform?

For apps that read the resource as JSON, the `@context` (and possible override) is not relevant

Overriding the context will affect the RDF semantics, and so it is important for publishers not to override

Aaron: in JSON-LD 1.1, it may be possible to use "@protected: true" the context, preventing overrides
https://www.w3.org/TR/json-ld11/#protected-term-definitions

Aaron: the proposal is to public the Solid-OIDC turtle vocab, and since it is for "solid-oidc", the URL `http://www.w3.org/ns/solid/oidc#` seems to make sense

Pavlik: this location makes sense, but we can revise it if necessary

Pavlik: we should define a full IRI from the namespace rather than define a rel Link relation from IANA

Henry: in his impl, the `rel="acl"` attribute is used as a shorthand for the full IRI. The shorthand is convenient for users

Pavlik: we should start with creating the vocab. In this case, these are not link relations, but just properties in a JSON resource.

Pavlik: can we agree that in the Solid namespace, we define what we need for Solid-OIDC? rather than going through IANA.

Henry: going through IANA is not as productive here, as they tend not to support using URLs for things

Pavlik: seems we agree on the way forward

### Solid-OIDC in non-browser environments

Aaron: In one case I start in a browser and get referesh token which can be used in cli etc.
Aaron: I've written solid-oidc broker which uses refresh token and refreshes them all the time. It's great for security but it is problematic in CI environment etc.
...: I've implemented client credentials flow, I don't love it but it becomes useful when one doesn't
want to deal with token refreshing. In that context what is id_token if any.

Pavlik: looked into device flow, but that seems to require initial setup, too, and may not work in this context.

...: possibly some variant of device flow, asking user to "go authorize with this code"

Aaron: does not currently have code that supports the device flow, but sees this as something that would be useful to support

Pavlik: this is relevant for the interop panel, esp. for CLI/bots 
...: provides a way to offload the browser component while still providing the same level of features



## Actions

* `@acoburn` to include `@protected: true` to the JSON-LD context and remove the text about overriding the context
* `@acoburn` to write solid/oidc vocabulary, defining terms
* `@elf-pavlik` to investigate use of Device Code grant
