owned this note
owned this note
Published
Linked with GitHub
# W3C Solid Community Group: Authentication Panel
* Date: 2022-05-16T14:00:00Z
* Call: https://meet.jit.si/solid-authentication
* Chat: https://gitter.im/solid/authentication-panel
* Repository: https://github.com/solid/authentication-panel
## Present
* Aaron Coburn
* Nicolas AS
* Abel Van den Briel
* elf Pavlik
---
## Announcements
### Meeting Recordings and Transcripts
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Use panel chat and repository. Queue in call to talk.
### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [Solid Code of Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md)
* If this is your first time, welcome! please introduce yourself.
### Scribes
* Pavlik
* Nicolas AS
---
## Agenda
### Issues
https://github.com/solid/solid-oidc/issues
### Open PRs
https://github.com/solid/solid-oidc/pulls
### Misc
* [Alternative Flows](https://github.com/solid/solid-oidc/blob/main/alternative-flows.md)
## Minutes
### Issues
* AC: Is there any conversation we need to have about the batch of new issues?
### Open PRs
* AC: The only PR is something that has been open for long time, we already discussed it before.
### Alternative Flows
https://github.com/solid/solid-oidc/blob/main/alternative-flows.md
* EP: Credit to Laurens for contributing extensively. The intention is to support clients acting on their own behalf, where there is no distinction between the Client and the RO. What WebID would be attributed to the client/RO then? Also, question abbout the clinet access control defaulting to closed.
* AC: Note that the WebID and the Client ID are being conflated in this case. How can we support this? One idea would be: it you have an existing Client ID document, and augmenting (potentially using a secondary JSON-LD context). You could use this context to reference key material. The server could generate a nonce as a challenge for the client to demonstrate possession of a private portion of the public key material available in their client ID/WebID document.
* EP: I think having apps acting on their own behalf could be an antipattern. There exists a distinction between clients and social agents which is described in the interoperability panel. An example is provided in the alternative flow document.
* AC: What you describe is a very typical use case (app acting on behalf of a social agent) can be implemented using offline_access scope and refresh tokens. App acting on its own behalf is a different use case which isn't covered by Solid-OIDC currently.
* NC: When you receive the refresh token you set timeout to keep access token refreshed as long as the session is active.
* EP: So refresh tokens itself don't have expiration?
* NC: Token response includes access token and refresh token which are opaque to the client and information about expiration for the access token.
* NC: When you restore persisted session, the refresh token is used to get new access token.
* EP: I see there is assumption that refresh tokens are long lasting, weeks not hours or days.
* AC: Using refresh tokens also often relies on the assumtion that some persistent storage layer is available.
* EP: There are proposed solutions in `alternative-flows.md`. In order to implement them and support the discussed use case, should the Solid-OIDC spec be extended, or should new specs altogether be proposed?
* AC: A difficulty we'll be facing is that device code flow/client credentials flow are OAuth2.0 contructs, while the ID token is an OIDC construct, defined at a different layer. We'll want to keep these concerns separate. Writing our own services makes that possible, but it will limit adoption of third-party software (e.g. CSS has faced issues implementing the client credential flow). Defining these will need to happen at the right level of abstraction.
* EP: +1. The first proposed solition (oauth token exchange) involves exchanging an oauth access token for an id token, so the distinction exists there. Same for using UMA, where the AS takes the ID token as a claim and returns any token in response. The AS would need to accept additional claims in order to support the use case we've described. Given this, is it interesting at all to keep using the ID token as a claim at all?
* AC: Both 1 & 2nd solution seems promising. It would require to define JWT format. If this format is used in context of token exchange we explain how it gets used there. If it gets pushed to UMA server we also would define it.
* EP: We would need to define a JWT that could be a VC (for example) and would be equivalent to an ID token but would not be the ID token itself
* AC: +1
* EP: If UMA would accept this sort of identity VC, there would likely be some sort of binding (DPoP or sender constraint).
* EP: It is not common to have a DPoP bound ID token. KeyCloak is implementing DPoP binding
* EP: For servers supporting client_credentials and ID tokens, the UMA server could support both formats
* AC: I think part of it comes down to what sort of flexibility exists in existing client libraries and server libraries. So the KeyCloaks of the world. To what extend those libraries can be reused. If we can devise mechanism that works with them we are in a good position. If we define something that deviates to far than solid community would need to release libraries for all languages. This would be a big burden for such (currently) small community to support.
* EP: agreed. Allowing support for UMA claims pushing, it gives us flexibility. If we (in future) support VCs, that could also use UMA.
* EP: Over time, there may be fewer ID tokens pushed as claims
* AC: I think the things we can do with VCs are pretty extraordinarry. The more we push community in this direction the better.
### Other items
Updates to self-issued openid provider (SIOP) now supports DIDs
https://github.com/solid/solid-oidc/issues/91
ACTION: EP will look into this work to see how this could be used in the Solid ecosystem for authentication
* AC: It would be great to see how SIOP fits into solid