Broaden panel scope, or defer until dependencies are ready? about authorization-panel HOT 8 CLOSED

👍 from me to broadening the scope of this panel to general Authorization (not just app-specific).

from authorization-panel.

Just to mention one more reason which I consider in favor of broadening the scope. While discussing @bblfish proposal of HTTP Signatures solid/authentication-panel#18 we also touched WebID Access Delegation. I see potential in unifying delegation and app authorizations into one feature that provides more granularity, user could delegate to app (authorize it) to have a subset of access modes that user has. Even if this direction turns out as dead end, it just makes sense to me to address all the authorization related aspects together.

from authorization-panel.

That there are overlapping issues between closely related panels is a point I made in issue 22: Thinking Authorization and Authentication together.

from authorization-panel.

It is true that there is overlap between Authentication and Authorization, especially along the axis of WebID (and possibly DID). However, it is worth noting the the technical infrastructure and protocols used by authN and authZ tend to be quite different; authZ is typically (though not necessarily) tied to a resource server while authN is often handled by an independent component using a variety of potential protocols (OAuth, OIDC, SAML, WebID-OIDC, TLS-OIDC, etc). But perhaps more importantly, the specification document produced by an authZ panel will be independent from the document(s) produced by an authN panel, which suggests a stronger level of separation. That said, I imagine that there will be considerable overlap in the participants of these two panels.

from authorization-panel.

To my understanding @RubenVerborgh suggests that we need to make progress on more broad AuthZ, to my understanding clarfy current state of WAC #33 and how we plan to use for App Authorization which currently acl:origin attempts to address in very limited way. As I understood we don't need to wait for AuthN panel to make progress.

Personally I think we should broaden the scope to general AuthZ, which includes:

• User Authorizations
• App Authorizations

I hope we can include it in agenda for our next meeting.

Where in practice User who may not have acl:Control access to the resource(s) can stll grant subset of one's own access to specific applications. Preferably WAC will provide vocabulary to handle both cases.

The overlap with AuthN seem to relate to identifying the User (WebID) and identifying the Application #30 where currently for both RS relies on information in token issued by OP.

from authorization-panel.

Today only 3 people could join the meeting and we didn't want to make that decision, let's try to prioritize it for next week or even try to agree earlier directly here in the issue.

from authorization-panel.

I think we can close this one since we resolved it last week

from authorization-panel.

Sounds good. Panel's been renamed, closing.

from authorization-panel.