Add Support for Client Identification and Issuer Identification

[uvdsl]

I would like to volunteer to contribute my bit to the Web Access Control specification, starting with this proposal.

Following up on my comment to #81, I propose to add the necessary terms to identify clients and issuers.

This proposal is a draft and intended as a productive conversation starter.
Please let me know which additional pieces are missing or require modification.

Requirement for Client Identification

Summarizing the write-up by Henry:
A resource owner must be able to restrict the extend to which a client, i.e., a software agent (application), has access to resources.

This materializes in two ways:

• restricting a particular client to a certain set of resources
• restricting the set of clients allowed to access resources

Either way, a mechanism to define which client to grant or deny access to certain resources is required.

Requirement for Issuer Identification

This ties into authentication but is also fundamental to authorization:
The ability to authenticate a subject agent, i.e., in particular to verify an asserted identity, role, attribute, capability, or similar, relies on identifying the issuer of the corresponding assertion.

For example:

• In WebID-TLS or in SIOPv2, the agent self-issues an assertion (the TLS-certificate or an OpenID token) to authenticate with a server. In such case, the issuer and the authenticating agent are the same entity.
• In Solid-OIDC, the issuer is the agent's Identity Provider who asserts that the user indeed logged in with them by issuing a corresponding assertion (the OpenID token).

The specification of a set of allowed issuers of such assertions (for identity, but also for other agent characteristica), enables to explicitly define the trust relationships that underlie the authorization process. This is crucial to verify a system's security.

Implementation Experience

Planned support:

• https://github.com/uvdsl/solid-wac-java (planned by and for myself)

Status unkown:

• There once was an implementation for CSS; @woutermont did you happen to publish it as a standalone component somewhere?

[termontwouter]

@uvdsl, I don't think I still have that code around ... It was hardly a few lines, of course, so not a big deal

[uvdsl]

@TallTed, thank you for your comments and suggestions. Much appreciated.
I left some comments.
I agree with the re-ordering to: Individual, Group, Class.

[uvdsl]

@termontwouter, thank you for sharing your implementation experience!

[csarven]

Thanks for putting this together! I'm excited to see this work out. I have long standing notes / draft changes related to this topic. I'll see if it makes sense to roll it into this PR or introduce them separately. Or introduce them first and then rebase this draft. We can discuss elsewhere.

I've left some minor inline suggestions (which I'll commit because they are more editorial). Below is a high level review on this work and considerations for next steps. Again, we can discuss.

--

Let's work through some considerations for introducing issuer*/client*.

I'd like some form of acknowledgement on the following in order to help us figure out best way to introduce issuer* and client*.

The notion of "issuer" and "client" are not universal or intrinsic to access control. They are context dependent. Making them core WAC concepts (being "required" with respect to an applicable Authorization) couples WAC to specific authentication models and so creates a long term extensibility risk.

Existing servers will ignore issuer* and client*. If clients start using them assuming enforcement, this creates a silent downgrade where access appears more constrained than it actually is. If issuer or client are treated as optional constraints that a server may or may not apply is also not a safe default.

Some directions:

We accept that WAC is evolving and allow issuer/client to be introduced with the expectation that servers will be upgraded in parallel. During this transition, clients should not assume enforcement until there is some awareness that there is at least adequate deployment.

We introduce feature detection where servers signal support for issuer/client. In its absence, clients must assume that the properties are ignored. This avoids the silent downgrade. It introduces complexity in order to be extensible. Assuming also that issuer/client are not the only extensions to WAC and so more prepared for the future when other authentication models are used.

[csarven]

Is there some background on issuer group and issuer class?

Introducing these may be complicating the authz mechanism.

The implications of issuer may be useful in some cases but quite limiting in others. I worry that it sets a precedent for only allowing agent WebIDs from certain issuers. In practice, this is similar to the "nascar" problem where a UI shows a fixed list of providers where one can sign in from.

That said, issuer can be useful, but I'm not sure I understand if issuer group and issuer class are necessary.

[uvdsl]

I'm not sure I understand if issuer group and issuer class are necessary.

In general, I just tried to keep the modelling style consistent:
To my understanding, the tuple of (agent,client,issuer) must be listed as acceptable for the authorization process to continue. This does not limit generality, e.g., to only define (agent, _ , _) where a specific agent can use any client and any issuer without restrictions -- as long as the absence of restriction is made explicit. This follows the usual WAC mode of deny-by-default, similar to acl:agentClass foaf:Agent explicitly states that any agent without restriction should have access.

• The acl:issuerClass and particularly in combination with foaf:Agent makes the absence of a (issuer) restriction explicit.
• The acl:issuerGroup is motivated largely to be consistent with the agent group. Indeed, this enables the exact functionality of restricting access to a list of (trusted) issuer. I fully understand (and am sympathetic to) the idea of not enabling this. However, from the functionality of restricting to a list of trusted issuers can be achieved using acl:issuer already by simply injecting the fixed list of issuers into each authorization rule.
• The acl:issuer is then at the core of the question here (i.e. whether to support it at all). The underlying security question is "who is able to specify whom to trust to assert an agent's identity/attributes/role/capability". The "whom to trust" may be more related to authentication than authorization but I think it may be valuable to enable making things explicit.

That being said, I am open to a discussion here, in the PR, or a separate issue (while removing the issuer stuff from this PR). I'd rather make small but steady progress rather than being stuck on one blocker.

[csarven]

I think merging this PR would address the client-identification issue so can be removed.

Suggested change

	<div class="issue" id="client-identification" rel="schema:hasPart" resource="#client-identification">
	<h3 property="schema:name"><span>Issue</span>: Client Identification</h3>
	<div datatype="rdf:HTML" property="schema:description">
	<p>Distinguishing social entities and clients: <a href="https://github.com/solid/web-access-control-spec/issues/81" rel="cito:citesAsRelated">issues/81</a>.</p>
	</div>
	</div>

[uvdsl]

Should that issue than be moved to the "Sources" note rather than deleting it completely?

[csarven]

Ah yes, we can do that. Let's come back to this. We can also link to this PR for source.

[csarven]

(See my overall review of this PR regarding feature detection)

To ensure backwards compatibility, issuer and client should be at most one rather than at least one:

Suggested change

	<li>At least one <code>acl:issuer</code>, <code>acl:issuerGroup</code>, <code>acl:issuerClass</code> property value (<cite><a href="#access-subjects-issuer" rel="rdfs:seeAlso">Subject Issuer</a></cite>).</li>
	<li>At least one <code>acl:client</code>, <code>acl:clientGroup</code>, <code>acl:clientClass</code> property value (<cite><a href="#access-subjects-client" rel="rdfs:seeAlso">Subject Client</a></cite>).</li>
	<li>At most one <code>acl:issuer</code>, <code>acl:issuerGroup</code>, <code>acl:issuerClass</code> property value (<cite><a href="#access-subjects-issuer" rel="rdfs:seeAlso">Subject Issuer</a></cite>).</li>
	<li>At most one <code>acl:client</code>, <code>acl:clientGroup</code>, <code>acl:clientClass</code> property value (<cite><a href="#access-subjects-client" rel="rdfs:seeAlso">Subject Client</a></cite>).</li>

but that would need to be accompanied with feature detection, e.g., via link relation (e.g., Link: <resource.acl>; rel="acl"; profile="..#client ..#issuer" for a server to signal that it will process issuer*/client* properties in an Authorization description.

[uvdsl]

I do see the benefit of backwards compatibility; I did not consider this.
My intention was to keep the "denial-by-default" mode of operation intact:

• If there is no client / issuer defined, then the rule is not meaningfully applicable, similarly to the case when the agent is missing.
• This forces an authorization rule to explicitly state the tuple (agent,client,issuer).

Leaving the issuer out-of-scope for now,

At most one acl:client

seems to be restrictive. I'd like to be able to use an object list of clients.

Can we somehow keep both "denial-by-default" and backwards comparability?

[csarven]

As mentioned, this is with the caveat that at least one client (and issuer) towards the applicability of an Authorization couples WAC with a specific category of authentication models. This is not in and itself bad but just narrows WAC, and I'm not entirely convinced that's how WAC should proceed. We may want to keep "core" WAC for what it is and look for ways that it can be extended in the context of different authentication mechanisms in use.

As for your intention to allow one or more clients with "at least", I agree that should be the case as well. So, from that perspective, I agree that "at most" is not accurate or intended. When I wrote that, I was thinking of backwards compatibility / silent downgrading - but this is not desirable either, which is why I mentioned feature detection may at least prevent clients from using issuer/client until they know for sure that the server has the capability and will enforce it. This may be one way to have both denial-by-default and backwards compatibility.

To be clear, even if backwards compatibility wasn't a concern, that is, say for example we can get a bunch of the servers to upgrade to handle issuer/client, there is still the perspective on being able to use WAC alongside different authentication models.

What do you think?

[uvdsl]

I understand that WAC should remain agnostic of any particular authentication mechanism to not limit generality.
I am not at all opposed to that. In-fact, I'd be happy if we can find a model that captures the core concepts that exist in every access control scenario, albeit in different manifestations.

The resulting conceptual question is then how to treat those concepts (like client or issuer) in a certain scenario where it is not immediately obvious how they apply.

Could you outline which authentication mechanisms you have in mind? I'd be intrigued to see whether certain classes/groups emerge, e.g., those using asymmetric cryptography, those using proof of knowledge, ...

---

See my thoughts below on the feature detection.

[uvdsl]

Thank you, @csarven, for considering this. I am happy to discuss and modify this draft.

I realize that this PR introduces two concepts: the client (as discussed in #81) and the issuer (as a related, yet undiscussed consideration for WAC). I deem resolving #81 more important as a first step. I'd be happy to move the discussion around the notion of an issuer into a separate issue to continue the discussion there.

On your remarks:

The notion of "issuer" and "client" are not universal or intrinsic to access control. They are context dependent. Making them core WAC concepts (being "required" with respect to an applicable Authorization) couples WAC to specific authentication models and so creates a long term extensibility risk.

I do acknowledge that this is the case for generic access control.

I'd argue that "client" is intrinsic to "access control on the Web" or "Web Access Control". Even if the "client" is just the browser, it is a software agent (application) that accesses resources on the Web on behalf of an agent.
Note that "client" and "agent" could maybe be the same entity, e.g. in case of autonomous agents on the Web (not going into legal debates here).

I acknowledge that the term "issuer" is indeed rather particular to authentication mechanisms that rely on asymmetric cryptography. On the other hand, if you consider the "issuer" to be more of a "provider of assertions", then even basic authentication is in-line with that terminology: The client (or agent) provides username:password, the server verifies the provided assertions by checking the database (instead of cryptographic verification), and accepts/denies the request. The authentication mechanism is a proof of knowledge (of the secret password) in this case. The provider is the agent itself.

Would you see room for discussion here?

Existing servers will ignore issuer* and client*. If clients start using them assuming enforcement, this creates a silent downgrade where access appears more constrained than it actually is. If issuer or client are treated as optional constraints that a server may or may not apply is also not a safe default.

Indeed, this is a problem which I did not yet consider.

We accept that WAC is evolving and allow issuer/client to be introduced with the expectation that servers will be upgraded in parallel. During this transition, clients should not assume enforcement until there is some awareness that there is at least adequate deployment.

This had been my assumption so far -- this would at least prevent new implementations from making the mistake of not supporting client restriction.
Now that you make this explicit this seems to entail a certain risk that I'd need to further assess. I'd be willing to assume eventual convergence...
Do you have or rather "is there" an overview of systems implementing WAC?

We introduce feature detection where servers signal support for issuer/client. In its absence, clients must assume that the properties are ignored. This avoids the silent downgrade. It introduces complexity in order to be extensible. Assuming also that issuer/client are not the only extensions to WAC and so more prepared for the future when other authentication models are used.

If such feature detection was added, I'd assume to exist a corresponding specification section on "optional features". However! The definition of client (and issuer) is NOT OPTIONAL from a formal security standpoint. These MUST be specified somewhere in the system. Implementers will expect them to be listed as required in an access control specification. If these were listed as optional, then implementers WILL skip them (been there, done that). This particular scenario prompted this work on the bundle of SSI specificaitons (DIDs,VCs,...). I'd rather put effort into convincing implementers to inject a default triple (<#rule> acl:clientClass foaf:Agent .) if they do not want to restrict clients.

That said, I am looking forward to discuss and modify this draft.

[elf-pavlik]

We had some related discussions almost 4 years ago, back in the AuthZ panel days

• Enforce a secure default for client restrictions authorization-panel#292

Since @matthieubosquet is back in action we could make another attempt and try to put our heads together.