# 2021-08-09 Authentication Panel

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

## Agenda

* actions from last week
* strategy for coordinating braking changes with pioneering implementations

## Present

* Aaron Coburn
* elf Pavlik
* Sarven C
* Barath R
* Nic AS

## Minutes

### Status documentation

@csarven We should document the publication state of Solid-OIDC. This is roughly equivalent to FPWD. What other working drafts should we expect? Are there major issues in the spec(s) that need to be addressed before we can talk about a ~Recommendation level?

@elf-pavlik once we enter ~CR status, we need to be more careful about breaking changes. At present with ~working draft, breaking changes are more possible.

Aaron: one of the changes could be need to scope for webid claim, I would like to clarify that.

@csarven: it would be good to itemize these things so that we have a path to CR.

@elf-pavlik it would be good to in-line the issues so that there is more visibility to how issues relate to text

### WWW-Authenticate

@elf-pavlik introduction of authorization server (Breaking change). This adds a new party to the flow and has a much bigger impact on the overall flow

### authentication-panel#128

@csarven: Should this issue be (renamed and) moved to solid/solid-oidc?

@elf-pavlik +1
@acoburn +1

### Coordination with implementations

@elf-pavlik What would be the best way to coordinate with implementations? Should the version of the draft be identified?

@nic on the client side, we try to avoid breaking changes. Backwards compatibility is preferred, or keeping support for OIDC access tokens for some time would be ideal. Is that do-able from a resource server perspective.

@elf-pavlik it would be great to support a smooth transition for early adopters. Three parties: Client, IdP, Resource Server. Where does the signaling happen?

@nic: if the protocol is versioned, we may have divergent features. It could be cumbersome for servers that partially implement the specification. Perhaps adding discoverability for the various features.

@barath: should backwards compatibility be avoided? This has historically been a vector for various downgrade attacks.

@elf-pavlik: from the perspective of CR state, everything would be required; this is more about deprecating features from the FPWD and providing a mechanism for early adoptors to upgrade.

@barath: my focus is on the transition away from the old state.

@elf-pavlik one could use the WWW-Authenticate header to discover the location of the authorization server. Which interactions would need which mechanisms for discovery? i.e. a different claim or scope

### Tests

@csarven: do we have an issue for test suites for Solid-OIDC? It is a rough requirement for CR status to have implementations. Is anyone working with Pete about the test suite. We should have a rough plan in place so that we know which parts of the spec have been implemented.

@elf-pavlik the intention of CR is that there will be no more breaking changes. Once we mark it as CR, then changes would only happen because they were found since the status change.

@csarven: typically changes come from experience based on implementation reports. That provides some room for the spec to change: dropping features, making modifications, etc.

@elf-pavlik we shouldn't mark Solid-OIDC as CR so long as there are known open issues. The CR status should be a high bar.

@acoburn has discussed a Solid-OIDC test suite with Pete, but no steps have been taken to make plans for the implementation of these tests

@csarven: at some point we may need to marks some of the tests (if that happens) as not reflecting current state of solid-oidc

@acoburn I see tests as very important but possibly not critical, other issues tend to take precedence. I'll take action to talk about it with Pete. We don't need to see it as all or nothing, what are the features that solid-oidc brings to OIDC which we need to test.

@csarven: we should test the features that the Solid-OIDC spec defines. Similar to the Solid Protocol spec, it borrows much from other specs, and it doesn't need to test every corner from those specs.

@elf-pavlik we should test the Issuer verification. Any predicate that is defined by Solid should be verified.

@csarven: we should focus on the features we're adding rather than testing other specifications.

### Misc

@acoburn: how do we get conversations that happen here out to a wider solid community, should we think about presenting in solid world, what would be most effective.
...: there are just couple of people attending the panel meetings, possibly couple of people who just read meeting notes. how do we go from those 10 max 20 ppl to 100s of people who may be interested?
@csarven: I don't think app developers will implement the authn specs, possibly they will grab libraries for their language. Specs are moving target, some implementers might be waiting for spec to get to CR status.
@elf-pavlik it would be important to invite implementers to reach out to the panel. That way the panel knows about the implementation and can address any issues/questions. Add a readme, for instance

## Actions

* @acoburn: adjust links in authentication-panel repository to point to new Solid-OIDC document
* @acoburn: migrate Solid-OIDC issues to solid/solid-oidc repository
* @elf-pavlik: add inline issues once migrated to new repo