2021-03-22 Authentication Panel

# 2021-03-22 Authentication Panel https://meet.jit.si/solid-authentication ## Agenda * [Meeting notes for 2021-03-15 #147](https://github.com/solid/authentication-panel/pull/147) (1m) * Any discussion/follow-ups to WICG/SolidCG meeting * re WICG https://github.com/WICG/WebID/issues/54 * WICG (Updated README as requested: https://github.com/WICG/WebID/commit/9ae80cc3e78c994bd555363343103ecaf476da98#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5 ) * Open question to document: What are Solid's needs that can be passed to WICG * [Proposal: change webid claim to solid #146](https://github.com/solid/authentication-panel/issues/146) * [specify parameters in WWW-Authenticate header #152](https://github.com/solid/authentication-panel/issues/152) * [Solid OIDC Conformance Classes #133](https://github.com/solid/authentication-panel/issues/133) * [Clarifying specific areas of overlap with AuthZ #145](https://github.com/solid/authentication-panel/issues/145) * [keyId's do not exactly refer to keys anymore #151](https://github.com/solid/authentication-panel/issues/151) ## Present * Henry Story * Aaron Coburn * Matthieu Bosquet * Sarven Capadisli * Elf Pavlik * Benoit Alessandroni ## Minutes ### Any discussion/follow-ups to WICG/SolidCG meeting Sarven: They added note to README mentioning name collision. ...: We should come back to them with what solid would need from web browsers. Create issue? Henry: Good idea to create an issue. It need to first implement HTTPSig, ACLs and then get to Credentials before I can start constructively looking at how we could work together. So my guess this will take 3 months before I can give an informed answer. Pavlik: I would follow their work especially what they do with 'directed identifiers' (site specific ones) Sarven: scope is identity/authentication but may even edgy stuff; native RDF parsing and serializing? ### [Proposal: change webid claim to solid #146](https://github.com/solid/authentication-panel/issues/146) Aaron: we have some +1 on the issue. Pavlik suggested using IRIs for claim names and for scopes. I generally don't see it in other systems but they can be used. Pavlik: if we don't want to use IRI we would need to regsiter that JWT claim Aaron: is solid is taking route of registering strings with IANA or using IRIs which we don't have to register Sarven: I don't know if we have global position on it, we did it for `acl` which has a history. `describedby` is registered by LDP spec. Aaron: In that case, if something we will change to using IRI sounds like linked data friendly approach. Sarven: If we think it can be used beyond solid we could consider registering with IANA. Henry: I'm worry about trying to move to something more general than WebID. If you try to specify other ways of doing things, we will need to add some parameters and values to tell difference. ...: I think JSON folks may look at IRI as something scary. Aaron: Those JWTs get sent with every authenticated request. Short claims like `iat` etc. allow more compact tokents. If we change it to IRI it takes more bytes. Pavlik: scopes have ofte IRI as values. Also we had proposal to exchange bigger token for short token used on each request, this would also go along UMA2.0 approach with delegating claims gathering. Aaron: Let's continue in issue. ### [specify parameters in WWW-Authenticate header #152](https://github.com/solid/authentication-panel/issues/152) Pavlik: ... Aaron: I think it is important to have something in WWW-Authenticate header Henry: WWW-Authenticate has standard on what you can put in that response header ...: HTTP-Sig has also system to use that header, some new spec came out to how to structure those headers Sarven: https://tools.ietf.org/html/rfc8941 Henry: https://www.fastly.com/blog/improve-http-structured-headers ### [Solid OIDC Conformance Classes #133](https://github.com/solid/authentication-panel/issues/133) Sarven: We were discussing documenting implementation, we tried to identify what kinds of implementation there are. Spec should indicate for each class what it needs to implement to conform. Pavlik: I could take action to add that section to the spec. Basing it ### [Clarifying specific areas of overlap with AuthZ #145](https://github.com/solid/authentication-panel/issues/145) Aaron: if RS needs to provide link to AS, how this would work with solid Pavlik: I mean AS associated with RS, distinct from IdP associated with user Benoît: As implementation its sometimes hard which pannel is responsible for which part Clarifying the overlap would help on implementation side Henry: In the HttpSig approach, the acl / ACR would be accessbile by the client and client would be able to find out there who has access. ### [keyId's do not exactly refer to keys anymore #151](https://github.com/solid/authentication-panel/issues/151) Henry: Sig headers have moved to the hs2019 algorithm, where the keyId has to specify both the key and other parameters such as sha516. As a result I think that the simple use of did:key I presented in the HTTPSig document does not work (it depends on what is in a did:key of course) ## Actions * Open issue or tag to collect ideas that can be brought to them in 3 months or so. * Pavlik: create PR with conformance classes