---
# System prepended metadata

title: 2021-06-07 Solid Authentication

---

# 2021-06-07 Solid Authentication

## Agenda

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

## Present

* Aaron Coburn
* elf Pavlik

## Minutes

### JSON-LD

JSON-LD Context issue - this has been sitting for nearly two weeks and will be merged, as the issues have all been addressed. If there are new issues related to this, they can be opened as separate issues.

### UMA

Use of UMA. There would be some additional token exchange with an UMA server. It would up to the resource server/UMA in terms of JWT or token introspection. Solid-OIDC would still be relevant for identity. A multi-RS scenario could still be supported.

Token exchange: an UMA server could exchange an ID token for an access token. Defining this exchange is worth considering: a resource server could serve as an AS. (or UMA server could be separate) This would allow a simple model for RS implementors while also supporting a more complex/scalable model. The ID token would likely need to be DPoP bound. The format of the access token could be completely opaque (not necessarily a JWT).

We may want to (re)consider the use of access tokens in Solid-OIDC. i.e. Solid-OIDC handles authentication, but authorization could be handled by the authorization server (UMA). Client identification would likely still happen at the authentication (Solid-OIDC) layer.

Perhaps a special-purpose call related (with a more formal diagram/description/proposal). UMA has also appeared in the authorization panel -- people from several panels would likely be interested.

### Verifiable Credentials


Pavlik: https://w3c-ccg.github.io/zcap-ld/
Pavlik: https://github.com/solid/authorization-panel/discussions/203


## Actions

Pavlik: create some simple sequence diagram with how UMA would work. (minimal change)