# 2021-09-13 Solid Authentication

https://meet.jit.si/solid-authentication

## Agenda

* Feedback from CSS developers
* [PR #43](https://github.com/solid/solid-oidc/pull/43) Rename Client WebID to Client Identifier - any final thoughts?
* client credentials flow
* [RFC7521: 4.2. Using Assertions for Client Authentication](https://www.rfc-editor.org/rfc/rfc7521.html#section-4.2)

## Present

* Aaron Coburn
* Joachim Van Herwegen
* Nicolas AS
* elf Pavlik
* Barath

## Minutes

### Feedback from CSS developers

Pavlik: I understand that CSS implements both Resource Server and Identity Server

Joachim: That is correct: there is an IdP component, as well as access control enforcement based which acts as an Identity Provider client on the RS side.

Pavlik: From the IdP side, do you implement everything from the current spec

Joachim: I have implemented ClientIDs but not the public one, because it is a bit of a hassle when working with the OIDC-library to use it.

Pavlik/Aaron: There is an open issue to reconsider if this Public Client Identifier should be kept in the spec. It being a hassle is an interesting feedback.
The purpose of the Public Client Identifier is to be a stepping stone from the current state of things to a place where clients all create their Client Identifiers.

Joachim: The issue is that all clients end up with the same Client ID, which is problematic in some cases.

Aaron: The problems (motivating its removal) are the following:
- It isn't dereferencable
- For an anonymous client, what is the value proposition of using the Public Client Identifier ? Using the same identifier for all clients loses correlation between one given instance of a client.

Joachim: The concept of having anonymous clients having less privileges is a good idea though.

Aaron: One use case is worth considering: how can you distinguish between an ephemeral client and regular client credentials ?
If such a distinction is necessary in some cases, then it could make sense to use an well-known client identiier.

/Aaron describes the client credential flow to make sure we all talk about the same thing/

Nicolas: OIDC spec recommends that ID token which you get back gets client id in `sub` claim.
*edit*: It is actually a contraint on the access token: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-12#section-2.2.

Aaron: I thought that is the `aud` claim. I will need to look into that

Joachim: In the diagram flows, what is the relationship between a resource server and an authorization server

Pavlik: there is a pre-existing relationship between a resource server and an authorization server. There are different options for token validation: token introspection (for opaque tokens), of JWT with public keys

Joachim: CSS is a highly modularized code base. In particular, the OIDC provider and the Resource servers are completely independent
services that simply receive requests from the same IRI origin.

Pavlik: If CSS implements the authorization server and the resource server running in the same runtime, then it would be possible to use opaque tokens that are placed in a shared persistence layer.

Joachim: If I understand correctly, the access token to the Resource Server would no longer need to conform to Solid-OIDC

Pavlik: That is correct. The access token generated by the authorization server only needs to be readable by the resource server. The access token does not need to be globally usable.

Pavlik: What is the access control mode implemented by CSS ? Does it implement WAC, and if so does it implement client access contro based on the Trusted App model ?

Joachim: CSS does impement WAC, but not Client access control.

Pavlik: It would be interesting to enable Access Control at the Client granularity, in a model where the Identity Provider and the Authorization Server are two distinct entities. One could present to the Resource Server an ID token from the Identity Provider, and an access token obtained from the Authorization server given certain client claims, in order to get a certain level of access to a resource.

Joachim: Part of the features of the OIDC Provider component come from an underlying library. It is an implementation detail, but that still means "regular" OIDC behaviours are much easier to support than custom ones.

Aaron: What sort of data/token structure are you planning to use for the authorization agent? Verifiable Credentials? JWTs?

Pavlik: I have been looking at [ZCAP-LD](https://w3c-ccg.github.io/zcap-ld/)

Nicolas: Can you describe what you are doing to support client_credentials?

Joachim: We have an open issue to look into client credentials, but that is the current state of things. There is currently no support for automation flows.

### Rename Client WebID to Client Identifier

[PR #43](https://github.com/solid/solid-oidc/pull/43)

Aaron: We expect client identifiers to be mostly serialized as JSON-LD, and to potentially be static documents. That means they would not necessarily be negociable as Turtle, which preventthem from being necessarily WebIDs (even though WebIds are a valid serialization too).

Pavlik: The JSON-LD serialization is the default one in the spec, and this behaviour is something IdPs who don't want to support RDF parsing would rely on.

Pavlik: If a JSON-LD document is stored in CSS, does deserializing it necessarily return it as is ?

Joachim: Depending on the backend used, it could be returned in a different framing, and the context could be lost.

Pavlik: It is only useful to have a MUST for the JSON-LD compact serialization if some compliant IdPs do not support RDF parsing.

Pavlik: If the Client Identity document is stored on a Solid Server backed by some kind of triple store/quad store, enforcing the compact serialization may be a burden.

### client credentials flow

Aaron: The biggest challenge we have faced with client_credentials flow relates to how to associate a WebID with a token from the client_credential flow

Nicolas: This will likely be an issue in CSS given the underlying library.

Pavlik: I have a question: since that affects only an Access Token, but we are interested in an ID token, does that provide a work around?

Pavlik: Who is doing the registration? Is it the user or the developer? In the case of tying a registration of a user, the WebID can be tied to the particular OAuth2 client.

Aaron: The way I've implemented this allows users to create OAuth2 clients that are tied to their particular WebID.

Pavlik: it would be best to use IRIs for the client_id values in client_credentials flow. That would make it easier to use that in RDF.

Aaron: The reason I have used strign literals is to avoid the issue of parsing colons in basic auth

Pavlik: Perhaps we can add a non-normative note to suggest using the request payload or to URLencode the client_id

## Actions