# 2020-02-24 Authentication Panel

## Present

* elf-pavlik
* jaxoncreed
* dmitri

## Issues

### [Proposed Terminology section #35](https://github.com/solid/authentication-panel/pull/35)

- Dmitri: I've updated it and merged PR
- Elf: I think it's pretty much done

### [Add section on optional client registration. #43](https://github.com/solid/authentication-panel/pull/43)

- Dmitri: It says that it's optional and client can proceed without it.
- Jackson: Nothing new here
- Dmitri: I took language from self-issued OIDC section
- Jackson: Using WebID as client_id sounds reasonable
- elf-pavlik: I mostly want us to avoid having multiple 'client ids'
- Dmitri: There's a bunch of stuff to mention about the types of clients and if they can use webids, and how we differentiate instances

### [TrustedAppsReplacement #61](https://github.com/solid/authorization-and-access-control-panel/pull/61)

#### example based on simple `acl:read` capability (elf-pavlik)

- Elf: I propose that we use a simple example of giving an app read only access. And I think that gives us a clear example of where to work around and how this capability works.
- Jackson: I try to create timline on bringing the trusted apps in. I've discussed it with spec editiors and we considered remivoving the current iteration on Trusted Apps from the spec.
- Elf: If we can't propose new replacement I prefer to remove current experiment than keeping it.
- Jackson: We plan to keep acl:origin, Michiel wrote and app that sets `acl:origin` for resources.
- Jackson: We also discussed caching in current implementations. As well as requirements for getting it included in the spec. We should work on reference implementation.
- Elf: Who will make PRs for the acl:origin? I think there's nothing about acl:origin in the specifications repo. From what I understand in our panels, we need to make a PR. Because I'd really like to see the concrete solution to the way the acl is defined. Becuase I think there's so many flaws with that as well. If that's defined in a decent way that's
- My main issue is with dependence on the origin header.

### [(WIP) Tokens and Credentials section. #37](https://github.com/solid/authentication-panel/pull/37)

#### VC - can verifiable presentation include vc by reference (`@id`) instead of embedding full vc (elf-pavlik)
- Elf: I didn't see a way to just include a reference to the presentation rather than the full credential.
- Dmitri: There aren't in the vc 1.0 spec a mechanism for that. I do think the [hash link](https://tools.ietf.org/html/draft-sporny-hashlink-04) mechanism would be appropriate. Part of the reason you can't reference by id, is that the contents should never change. A hash link allows you to bind a URL to the hash.

#### identifying client - when RS can only rely on `cnf` used for sender constrained credentials.Ja
- Elf: this also relates to the trusted apps replacement PR, where it relies on the webid of the client. Like when the resource server trying to verify the id. In the case where we don't want to put responsibility on the resource server, I think in most cases we can rely on the binding of the client. I don't think the RS needs to go beyond the dpop token. If we work on the use cases where the user restricts the client. You don't need the webId of the client.
- Jackson: What I detail in my PR I see less importanta as restricting the client but I see it requested. From RS perspective if token doesn't include WebID of a client, it consider request to be made directly by the user. I think granting app power to say "I'm the user making the request" would require higher level of consent.
- Dmitri: I see here different classes of clients, and how we can identify them.
- Jackson: More strongly identifiable clients may request lower threshold of consent.
- Dmitri: I think it depends on what user gives access to.
- Jackson: I see distinction as access as user or user using certain application.
- Dmitri: Where do you see scenario of access as user rather than using application?
- Jackson: If I access as user, it means that any ACL made for an app doesn't apply. One could still constrain the token. We should discuss if we allow it or not.
- Elf: For me, the ony case where we have direct access is when the user navigates the browser directly. Then the resource server acts as the client. Then there is some session established directly between the resource server acting as a cleint and a user.
- Dmitri: In those cases the pod itself also acts as an OAuth relying party. When you do a direct browser request, the pod acts as a relying party.
- Jackson: So in that case, Pods would have a special app webid.
- Dmitri: Yes, it would be theoretically possible for a user to say don't let a pod's client act on its own resource.
- Elf: I also think the blacklist in the proposal is less important from than the whitelist.
- Jackson: By default everything is allowed, and then you can make an effort to go in and include a whitelist.
- Elf: You want to have an explicit way to say every client is allowed.
- Jackson: We discussed with TimBL to create a new authorization class for whitelists. This would apply for any optional ACL rule. https://github.com/solid/authorization-and-access-control-panel/pull/61/files#diff-c5f579abe0451cde312e9e6d319c3c6aR34

#### can user act as vc issuer by, besides of `solid:oidcIssuer`, also add public key used by OP to user's WebID profile? (OP could even create per user key pair) + [consider support for OIDC self-issuer #11](https://github.com/solid/authentication-panel/issues/11)

- Elf: by adding the public key directly to the users webid could the user act as its own vc issuer. The user is the issuer. The client is the subject/holder. And the resource server is the verifier. In that case we can have the capability for the user in general. We also don't need to id credential because we can get the issuer webid from the capability credential.
- Dmitri: There's two questions. One is who is the issuer.
- Dmitri: If the user is the issuer does it make sense to put the signing key in the webid
- We're going to use DiDs in the future instead of webids, so the keys that the user is signing the capabilities with is in the identifier document. The problem we have is with the state of wallets. The reason we use the OP is because we want it to be used as a wallet. The semantics of the OP signing this is that "I the OP has had the conversation with the user so I can use my keys to present this credential." It is a valid point that is complicated by the state of wallets.
- Elf: How differently would a credential look if the user was using a local wallet vs if it's using an idp. My suggestion is that since we already need to use the openid issuer they could just put the key in one's own profile.
- Dmitri: This delegation chain is handled in linked data authirizations spec. We don't need to come up with mechanism for it. Eg. I user with DID authorize this OP to sign credentials on my behalf.
- ...: I see it as complementary method to what we currently have.
- Elf: We don't want to eliminate the `solid:OIDC` to assist clients to discover the issuer.
- Elf: I think we need User's WebID in capability credential anyhow and than we don't need separate id credential.
- Jackson: Every token in solid would get verified ...
- ...: It seems simple having less 'switches', as cons i see it less semantic as of what happens
- ...: In whitelist on issuer we need clear notion of the issuer distinct from the user
- Elf: this case seem to disallow self-issued
- Dmitri: If decide that capability credential has similar lifespan than capability credential it may work.
- Jackson: When I talk to RS i may want to have separate id credential
- Elf: I think we need to couple capability and id credential anyways to preven client from only presenting id credential and hiding capability credential from RS.

#### VC - revocation, expiration, refreshing / renewal (elf-pavlik)
- Dmitri: it doesn't seem clear what lifespans should be.