---
# System prepended metadata

title: 2021-03-29 Authentication Panel

---

# 2021-03-29 Authentication Panel

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

## Agenda

* [meeting notes 2021-03-22 #154](https://github.com/solid/authentication-panel/pull/154) (1m)
* [Define Solid-OIDC requirements for what client description WebID Document should include #75](https://github.com/solid/authentication-panel/issues/75)
* [support DID-JWT?](https://github.com/solid/authentication-panel/issues/157)
* [ontology security](https://github.com/solid/authentication-panel/issues/156)


## Present

* Dmitri
* Aaron Coburn
* Matthieu
* Henry Story
* Elf Pavlik
* CSarven

## Minutes

### Define Solid OIDC issue
 [Define Solid-OIDC requirements for what client description WebID Document should include #75](https://github.com/solid/authentication-panel/issues/75)

Elf: by whome is the data used?

Aaron: An Application identifier may support for example not support  authentication identifiers. If the data that is entered in to the authorization endpoint is not include in the client identifier data set then the request fails.

Ultimately the server has allow lists for these values. If the server says it does not support implicit flow, but the flow is not included in the allow list.

There is a server defined set and a client defined set and the intersection is what the server is allowed.

Dimitri: it is strange to have json embedded literal in the rdf, as with json-ld one can easily make it work both with with Turtle

The OpenId group with the CCG is starting to work on something very similar. I was talking with Mike Jones and Kristina Yasuda from MSFT and they were looking towards entity statements OpenId connect version of App WebID. https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.6.1.2

Similarly CCG has arrived at the same place (data resolvability) for their Wallet, in ther [Connection](https://w3c-ccg.github.io/universal-wallet-interop-spec/#connection) objects. The user has granted this App such and such ...
(similar to the access request spec done with Interop).

Henry: Each app has this json description, do we have problem of privacy issues here?
Elf: it's in app's document not user's document
Henry: Ah ok. I thought this could be leaking information. 

Henry: In the case of JWT it makes sense to put data in a JSON literal, as it is difficult to change the format, and is also a lot of work to get an security ontology. But here we have JSON that really contains linked data. So I think here it makes more sense for a link to a JSON-LD document.

Aaron: I think we can get an egreement on having a link to a document that is required to be a JSON-LD document with a given context.

CSarven: Json-ld sounds good.
  I want to backtrack a bit, to the discussion of what we expect of a WebID document serialisation. 
  
Henry: Thinking this is not a WebID Profile document. For a person this would make sense as HTML.

Aaron: We have been calling it a WebID document.
  
Aaron: We are using the term WebID in the spec where we problably don't need to. 

Elf: It makes sense to have a WebID of an Application as well as that for a user. The requirement comes from the WebID spec returns a Turtle spec.

Dimitri: A WebID.

Henry: right a WebID identifies an Agent, and a client is an agent.

Matthieu: WebID is the correct term for http URIs that refer to agents.

CSarven: would you find a human readable web page for this client ID? Consider that Dokieli could have a home page that human readable page.

Consensus: Work on JSON-LD version.

### support DID-JWT?

[Support DID JWT](https://github.com/solid/authentication-panel/issues/157)

Dimitri: there is a WG for security ontology in the works at the W3C.

Henry: cool.
  Wondering why the hashing was removed from the last draft-cavage specs. Could one sign the headers directly with RSA to allow did:jws or did:key? 
  
  
## Actions

