# 2021-06-28 Solid Authentication

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

## Agenda

* State of Solid OIDC and publishing a ~FPWD
* [Clarifying specific areas of overlap with AuthZ #145](https://github.com/solid/authentication-panel/issues/145) -- why is this relevant? -csarven
* [Document implementations #128](https://github.com/solid/authentication-panel/issues/128)
* [Solid OIDC Conformance Classes #133](https://github.com/solid/authentication-panel/issues/133)
* Add Solid-OIDC related vocabulary resources [solid/vocab#51](https://github.com/solid/vocab/pull/51)
* Publication date?
* Drop WebID terminology for client profile document https://github.com/solid/authentication-panel/issues/75#issuecomment-868291622
* Scope value requirements? [See #86](https://github.com/solid/authentication-panel/issues/86)
* `webid` claim vs `solid` [See #146](https://github.com/solid/authentication-panel/issues/146)

## Present

* Aaron Coburn
* elf Pavlik
* Sarven C
* Henry Story

## Minutes

### State of Solid OIDC and publishing a ~FPWD

Sarven: we should have an understanding of where things stand with Solid-OIDC and the time frames involved. What would constitute a ~FPWD and when can that be available?

... The solid protocol refers to Solid-OIDC as the primary authentication mechanism so this document is a dependency on the protocol spec.

... We should discuss moving Solid-OIDC into its own repository as a sign of its maturity

Pavlik: if we still have a ~FPWD we can still make "breaking" changes. So there is a low bar here. We could consider what we have now as ~FPWD because we are not committed to having everything stable at this stage

Sarven: As a CG, we have fewer strict requirements about what constitutes a ~FPWD. Should we ack that this is at ~FPWD stage? (We may need to think more about the terminology used)

Pavlik: we don't want to send misleading signal that it's on a REC track.

Sarven: For CGs we can have an editor's draft and a final report, but we will need to be aligned on what we mean with the document status

Pavlik: the important thing is to not yet be committed to making no breaking changes. We can't currently commit to no breaking changes.

Aaron: there are experiments with other AuthN mechanisms: UMA, GNAP, OAuth2, etc. We'll want to clearly define Solid-OIDC as an AuthN mechanism without cutting off other possibilities

Sarven: We seem to be aligned on the general state of the Solid-OIDC document

### Overlap with AuthZ

[Clarifying specific areas of overlap with AuthZ #145](https://github.com/solid/authentication-panel/issues/145)

Henry: I [noticed last week that the security:publicKeyJwk](https://github.com/solid/authorization-panel/discussions/225) subject is the same as a WebID - it refers to an Agent that is identified by a http URL. So an area of overlap is that it should be possible to identify a user indirectly via their `security:publicKeyJwk` relation to a JWKey. This suggests that the relation should be available to be used in WAC. That is relevant in the case of HttpSig as that uses the JWK vocabulary to identify users.
Documented this [in the comment to issue 225]( https://github.com/solid/authentication-panel/issues/145#issuecomment-869742430).

Sarven: why is this issue relevant for AuthN

Pavlik: currently OIDC describes AuthN, but we also issue access tokens. This may be going too far because it oversteps into authZ. One possible option is where Solid-OIDC may only issue ID tokens that are exchanged for access tokens.

Sarven: is this something that should be resolved before publishing a ~FPWD

Pavlik: we shouldn't claim stability in the spec, so this isn't an obsticle. There may still be major breaking changes.

Aaron: re access/id tokens, +1 on importance. not required for ~FPWD. open question that needs to be resolved: whether soid-oidc is overstepping its bounds.

### [Solid OIDC Conformance Classes #133](https://github.com/solid/authentication-panel/issues/133)

Sarven: we need a section on specifying the classes or roles required in the spec by server/client

Pavlik: will follow up. See Actions below.

### [Document implementations #128](https://github.com/solid/authentication-panel/issues/128)

Sarven: Need more information from CSS

... no hard requirement on the number of implementations, but it shows the level of committment. It also signals that this is something real and not just a document

... this is not required for ~FPWD

Pavlik: It would be great to link to issues directly from the spec. Bikeshed has a nice feature to make this easy. Will follow up with a relevant PR

### [Add Solid-OIDC related vocabulary resources solid/vocab#51](https://github.com/solid/vocab/pull/51)

Sarven: this looks good, as-is. The vocab term status is "testing", which is appropriate for these documents.

... will shepherd this PR through

... Do we need a repo for Solid-OIDC? Thinks there _should_ be a repo, but we'll need to consider existing links.

Pavlik: the protocol spec will link to the published document rather than the GH repo itself

Aaron: currently the document location is tied to the authN panel repo because we're using GH pages to publish the document

Sarven: 1) create solid-oidc repo and use it as editor's draft, and publish the rendered version. 2) pr a ~FPWD to solid/specification (to be published under solidproject.org/TR/soid-oidc ) and have it link to the editors draft (in 1).

Pavlik: it would be inconvenient to have duplication of text. Can we use `git subtree` for this? Will investigate

Sarven: Editor's draft is more like a living document. Will that work with this process? If the Solid-OIDC repo is dynamic, can the protocol link to a specific version?

Pavlik: will look into this, but generally it should be possible to pin to a specific commit

Sarven: would like to know how this is done so that it can be repeated for others (WAC, etc)

... for long-term, this will be relevant

Pavlik: we can take this up as an issue next week

### Publication Date

Sarven: what works for the editors? Considering the issues we have to look into

Aaron: if repo etc are resolved, ~2 weeks or so

Pavlik: majority of the spec is aligned so should be July.

### Drop WebID terminology for client profile document https://github.com/solid/authentication-panel/issues/75#issuecomment-868291622

Aaron: Issue now looks at how we use WebID term to describe client identifier. WebID
makes `text/turtle` the default content type. In Solid-OIDC we make `application/ld+json` the
default content type.
...: In my opinion we try to address requirements of OIDC ecosystem which prefers JSON.
With current `@context` we make it JSON while still providing RDF data.
...: We have this conflict while we call it WebID
Henry: I don't think this is important, it can change. I don't see the default mime type, as essence of WebID.
Serialization preferences are fashion trends.
...: It seesm we have an HTTP URL that identifies an agent, via say links to other things, eg. link to OIDC Issuer
Pavlik: This link is in user's document not client's document.
Henry: I have editor access to that spec, I could possibly change it.
Pavlik: Suggested removing the WebID terminology with a link to an issue
...: Spec should be consistent
Sarven: Is Solid-OIDC use of WebID in the context of the Solid protocol or in the context of the WebID specification?

### Scope value requirements? [See #86](https://github.com/solid/authentication-panel/issues/86)

### `webid` claim vs `solid` [See #146](https://github.com/solid/authentication-panel/issues/146)

## Actions

Pavlik will follow up on #133 (IdP, Resource Server, Client; there may be other roles)

Aaron will follow up with CSS team to find out about the status of CSS

Pavlik to update Solid-OIDC to include links to issues.

Sarven will follow-up on solid/vocab/51 to get it merged.

Pavlik: will investigate how not to duplicate text across solid/specification repo and a new solid/solid-oidc repository