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.

[csarven]

Some thoughts:

For instance, the notion of client is not particularly meaningful in the case of WebID-TLS.

Interestingly, the notion of issuer has a meaning in X509 certificate that's used by WebID-TLS. For self-signed certificates, issuer is typically the origin of a WebID. But in other cases, it'd another CA. From that perspective, I can see that issuer has some meaning that could be expressed in an Authorization field (although that's something that was not done in the past in WAC).

Right that something like ZKP doesn't inherently have client/issuer roles.

As I understand it, generally when a third-party is involved, the notion of issuer becomes more relevant. When an actor vouches for their own identity, that may effectively be equivalent to one being their own issuer I suppose.

Again, as I understand it, when something like HTTP Message Signature is put to use to sign requests ( e.g., Henry's https://solid.github.io/httpsig/ ), I'm not sure if client plays a particular role but it doesn't exclude the possibility either.

[elf-pavlik]

When exploring those possibilities it might be useful to review

• https://openid.net/specs/openid-connect-self-issued-v2-1_0.html
• consider support for OIDC self-issuer solid-oidc#91

[uvdsl]

For instance, the notion of client is not particularly meaningful in the case of WebID-TLS.

Well, yes and no.

In the particular instance of WebID-TLS (or maybe transport layer authentication in general?), the notion of a client is indeed not deemed too relevant as authentication is executed on the transport level rather than application level.

However, this does not entail that the notion of a client is not applicable in this instance. There exists a client which initiates the communication with the server; be it curl, a browser, or some application (e.g. native app or a web app in the browser). In WebID-TLS, the client can just not be identified -- but this does not mean that it is meaningless -- on the contrary, it means that ANY client can/could be present when authenticating via WebID-TLS. The server has no mechanism to check which particular client is used by the authenticating agent. To make this explicit, I recommend mandating ... acl:clientClass foaf:Agent. if ANY client may be used (for whatever reason). If a rule states that only a particular acl:client may be used, then WebID-TLS does simply not provide the security guarantees desired and required by the resource controller / server.

Therefore, the notion of client is indeed very relevant to WebID-TLS albeit through its absence.
As you desire WAC to remain general, I believe WAC to remain general when introducing acl:client restrictions (or the explicit lack thereof). It only enables definition of more specific access control rules -- in a generic manner.

Interestingly, the notion of issuer has a meaning in X509 certificate that's used by WebID-TLS. For self-signed certificates, issuer is typically the origin of a WebID. But in other cases, it'd another CA.

Exactly, and this pattern is generalizable.

Right that something like ZKP doesn't inherently have client/issuer roles.

Depends on the protocol -- and again, this does not limit generality. Just because something seems absent in a certain case does not mean it is not relevant to it in general (see WebID-TLS).

Again, as I understand it, when something like HTTP Message Signature is put to use to sign requests ( e.g., Henry's https://solid.github.io/httpsig/ ), I'm not sure if client plays a particular role but it doesn't exclude the possibility either.

Yes, as HTTP Signatures operate on the application layer (SIOPv2, Schnorr-based), they are capable of indicating which client the authenticating agent is using.

[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.

[uvdsl]

This issue was mentioned in the CG Weekly Meeting on 2026-02-04.

[csarven]

Some comments. Will come back to other questions/comments you've made.

We should not conflate HTTP client with the application-layer notion of OAuth/OIDC client identity. WAC operated without needing to distinguish which application a user is running.

We need a concrete mechanism for feature detection, like in the Link header or expressed in ACL resource.

If we can approach splitting the client from the issuer feature, that'd also be great. It needs to be clear that one does not depend on the other. And how both servers and clients should behave when the requirement information is missing. I suggest we focus on a smooth-and-safe-as-possible upgrade path. (I'll come back to this..)

We may also need to upgrade error responses, i.e., when a WAC-next server rejects a payload.

I agree that when the notion of client is introduced, then it makes sense that "any client" is expressed like acl:clientClass foaf:Agent.

I also have concerns about who controls the client identifier namespace and how stable those identifiers are for (long-lived?) access control rules. "URI ownership"-all-the-way-down.

[uvdsl]

Hi, I'd like to quickly summarize some thoughts here as well:

Feature Detection: I would support that also given that there may be other features like time-based as proposed in #37 access or attribute-based access as done in SISSI (see Sec. 5.2).

We should then consider whether the notion of client and issuer are generic enough (occur in a generic way in many/all access control mechanism -- in some form) to be deemed part of the core model of WAC or whether those are not generic enough and thus would be deemed a feature as well. I currently lean towards them being core, but I'd love to hear counter-arguments...

In any case, adding the feature mechanism would mean that there is the core model which operates on denial by default in combination with feature models that might operate slightly differently, namely if a statement regarding time (or other) is missing, then a default value is assumed.
This then means that only the core model is considered when determining which rule is applicable.

Looking forward to discussing!

[uvdsl]

Addendum: Maybe the above mentioned concepts are "conditions / restrictions / constraints" on the authorization rule. I recall the notion of "authentication context" being used elsewhere (but do not recall where exactly).

Notably, NIST SP 800-162 provides helpful definitions -- but it assumes that

subjects are bound to trusted identities or identity providers

NIST SP 800-63-4 refers to issuers as credential service providers (CSPs) or identity provider (IdP).

Additionally, MS Entra has similar concepts, and it attaches the issuer (CSP) to a particular attribute being attested.

With this, I am leaning towards defining "constraints" (?) on an authorization rule.
These may include and are not limited to client/app, IdP, attribute and CSP, time, location ...

If no constraint is present, no constraint is evaluated.
Which constraints a server supports could be advertised via the discussed feature discovery.
This would also allow for nicely separating the core model from the constraints such that constraints are not directly attached to the rule but are linked to the rule via a rule-(multi)-set, maybe.

Addendum 2: Maybe, it is worth considering an additional class ConstrainedAuthorization (disjoint with the unrestricted Authorization), such that legacy servers do not accidentally find an Authorization Rule that is indeed constrained but then ignore those constraints... I currently believe that this would be the cleanest and safest approach to upgrading.

[uvdsl]

I would like to share the model that emerged in my mind. Apologies for the long comment.

TL;DR

I believe we should keep WAC as is, and instead of modifying it, we should create an true extension that is grounded in WAC. Such pattern may also be applicable to requesting access to a resource as well.

I see currently two ways forward: (1) using Named Graphs, or (2) using terms whose semantics are carefully specified and explained.

---

(Core) WAC

The core of WAC is essentially what is currently in the specification. It allows to describe Authorization Rules that grant an agent access to an information resource in specific access modes. Notably, acl:Authorization asserts unconditionally (i.e. without restriction) that the agent is being granted access. Crucially, it does not mean that an agent "should have access" which would water down the ACL semantics. If the graph where an acl:Authorization is described is assumed to be true, then the rule applies and the agent is authorized.

Conditional Web Access Control (CWAC)

In certain use cases, conditions may apply to the "environment" for authorizations to become applicable. For instance, the certain client and issuer or a certain time may be the condition to be granted access to a resource.
I propose to handle such conditions (which are conditions on the environment -- not on the authorization rule itself -- by linking the rule to a set (object list?) of "Conditions" that jointly must hold for the authorization rule to be in effect.

The notion of in effect already hints at the fact that a conditional authorization rule is different from acl:Authorization in its semantics. With a conditional authorization rule, the agent at hand is not always granted access, despite an authorization rule (albeit a conditional one) existing.

Because acl:Authorization describes an unconditional/unconstrained/unrestricted authorization rules, we cannot simply define an subclass -- ex:ConditionalAuthorization rdfs:subClassOf acl:Authorization would lead to a logical inconsistency: A conditional authoirzation is not a subclass of a unconditional authorization.

---

Example:

<#rule> a ex:ConditionalAuthorization; 
    acl:agent ex:alice ; 
    acl:accessTo </doc> ; 
    acl:mode acl:Read ;
    ex:conditions [ ex:client ex:photoApp ] .

If ex:ConditionalAuthorization was defined as rdfs:subClassOf, then an access control system might entail under RDFS entailment:

<#rule> a acl:Authorization, ex:ConditionalAuthorization; 
    acl:agent ex:alice ; 
    acl:accessTo </doc> ; 
    acl:mode acl:Read ;
    ex:conditions [ ex:client ex:photoApp ] .

Assume now that Alice (ex:alice) sends a GET request to </doc> using some other client ex:travelApp.
The access control system might check whether there is an ex:ConditionalAuthorization where conditions are fulfilled but there are none fulfilled.
Then, the access control system might also check whether there is an unconditional acl:Authorization that would grant Alice access -- as this is how acl:Authorization is defined. It has been so for a long time and is implemented in various systems: in old systems, there simply might not be a check for our new conditions implemented.
And this query for acl:Authorization then yields that Alice is indeed authorized -- and the conditions on that rule are ignored.

---

This means that CWAC requires a different operational semantics than WAC.
But this is fine, because we can treat CWAC as a true extension to and being grounded in WAC.

CWAC introduces the notion of environment for which particular conditions may be required to hold in order for access being actually granted.

Kindly ignore the following formal grounding:
Let $E \in \mathcal{E}$ denote a particular environment from the set of all possible environments.
Let $C = \{c_0, c_1, ... , c_n\}$ denote a set of conditions, e.g. client, issuer or time, where $C \in \mathcal{C}$, the set of all possible condition sets.
Let $eval: \mathcal{E}\times\mathcal{C} \mapsto \{0,1\}$ denote the function to evaluate a particular environment against a set of conditions that must hold, resulting in a boolean value whether or not the environment satisfies the set of conditions.

Let's then assume a new namespace cacl.

<#rule2> a cacl:ConditionalAuthorization; 
   # ...
    cacl:conditions [ cacl:client ex:photoApp ] .
}

Now I see two options for expressing the details (subject,object,modes) of this conditional authorization rule.

Option 1: Named Graphs

<#rule2> a cacl:ConditionalAuthorization; 
    cacl:rule <#ruleGraph>
    cacl:conditions [ cacl:client ex:photoApp ] .

<#ruleGraph> {
    <#rule> a acl:Authorization; 
        acl:agent ex:alice ; 
        acl:accessTo </doc> ; 
        acl:mode acl:Read ;
}

Operational Semantics: Using Named Graphs, we are able to express that a certain rule graph is only to be considered asserted (and thus true) if the conditions of the conditional authorization $\textit{eval}$ to true against the environment.

We do not need to re-define acl terms but provide context (graphs) -- see also W3C Context Graph CG or Pieter's RDF messages -- to an existing technology. But Named Graphs come with their own set of challenges...

Option 2: Terms for Intent

<#rule2> a cacl:ConditionalAuthorization; 
    cacl:agent ex:alice ;   # intended subject
    cacl:accessTo </doc> ;  # intended object
    cacl:mode acl:Read ;    # intended modes
    cacl:conditions [ cacl:client ex:photoApp ] .

As the usual WAC properties are defined to have rdfs:domain acl:Authorization but a cacl:ConditionalAuhtorization is not a subclass of that, we do need to redefine the 4 or 5 properties in the cacl namespace.

Operational Semantics: By defining the semantics of calc:agent etc that these express intent for authorization, we are able to express that a corresponding acl:Authorization may be entailed (and thus true for the current authorization process) if the conditions of the conditional authorization evaluate to true against the environment.

Given an environment $E$ for a particular request to </doc> by ex:alice:
If $\textit{eval}(E,C)=1$ then it can be entailed in the current authorization process:

_:rule a acl:Authorization; 
    acl:agent ex:alice ; 
    acl:accessTo </doc> ; 
    acl:mode acl:Read .

which states that ex:alice is indeed authorized to read </doc> .

Note that this entailed rule should not be materialized because it is tied to the potentially dynamically changing environment.

Note that an access control system might thus simply check the conditions and then directly make a decision using the "intended" (subject,object,modes) information -- no need for the logical gymnastics here.

---

Bottom line: I believe we should keep WAC as is, and instead of modifying it, we should create an true extension that is grounded in WAC. Such pattern may also be applicable to requesting access to a resource as well.

---

EDIT: On the idea of using an object list to define conditions that jointly must hold -- I believe this goes against WACs usual set aggregation semantic of object lists. I think object lists should be used for handling OR (i.e. union) of (sets/lists of) conditions.

[elf-pavlik]

Why isn't cacl:agent just another kind of condition? There are long documented use cases that one may set policy that only requires certain credential - verified age, membership in organization, educational etc. In that case cacl:agent condition wouldn't be used at all. One of the reasons we looked at UMA was that it already has pretty well defined mechanism of claim pushing and AS can express which claims are required for the cilent to push/present based on UMA ticket.

[uvdsl]

Just quickly: If you do not need to identify the agent with its WebID, then you do not need to use cacl:agent. The above is just one usage example that does not claim applicability to all of your particular use cases.

I would find it strange to define the subject of authorization as a condition on the environment.

If you want to express Attribute-based Access Control, you still need to authenticate an agent, therefore, the rule could read

<#rule2> a cacl:ConditionalAuthorization; 
    cacl:agentClass acl:AuthenticatedAgent ; # intended subject
    cacl:accessTo </doc> ;  # intended object
    cacl:mode acl:Read ;    # intended modes
    cacl:conditions [ ... attribute/credential condition ... ] .

[elf-pavlik]

https://solidproject.org/TR/wac#acl-agentclass-authenticated-agent

Allows access to any authenticated agent.

Woudn't in your last snippet, agent being authenticated be implied simply by meeting the required conditions? Would there ever be a case where all conditions would be met but somehow the agent wouldn't be considered as authenticated?

I see it related to renaming End-user Credential to Authentication Credential in LWS w3c/lws-protocol#56 and recognizing that it might not be appropriate if Authorization comes into the picture and client will present claims used for AuthZ other than ID Token or equivalient.

While I think there may be a case of just user AuthN with the client. When it comes to the storage/pod AuthZ always seems to be the goal and AuthN is only coming into the picture if AuthZ uses agent identity (agents identitties if we distinguish the clietnt) to define AuthZ policy. Depending on policy storage may want to authenticate identiy of each

• end user / requesting party - Id token, signature etc.
• client - eg. using authn on token endpoint or trust user's issuer, or restrict issuer
• issuer - even by relying on TLS certs

Still if access policy doesn't require verifying (authenticating) any of those identities, and for example only requires specific VC, do we even have AuthN in play?

[elf-pavlik]

I guess more than acl:AuthenticatedAgent something in lines of cacl:AgentMeetingConditions could work

<#rule2> a cacl:ConditionalAuthorization ; 
    cacl:agentClass cacl:AgentMeetingConditions ; # intended subject
    cacl:accessTo </doc> ;  # intended object
    cacl:mode acl:Read ;    # intended modes
    cacl:conditions [ ... attribute/credential condition ... ] .

I recall back in the days Henry was experimenting with defining agent classes using OWL restrictions. There must be an issue capturing it somewhere. Possibly a data shape could be used as well 🤔

Still end-user / requesting-party identity looks like just another condition to me.

[uvdsl]

Again, quickly: In my proposed model, the conditions are specified to be evaluated against the environment. Not the authorization subject. There is a distinction to be made between the authorization subject, i.e. the agent, and the (authentication) environment the subject operates in.

Note that this is very similar to what you describe with UMA claim pushing:
UMA claim pushing modifies the environment in which conditions are evaluated for an authorization subject. It does not alter the agent.

[elf-pavlik]

Id Token was one of possible claims that could be pushed to UMA AS. I'll follow this issue but I still don't see how you draw a hard distincion between the agent and the environment. Verifying identity of agent seems to me just one of aspects of the environment. Also if end user uses a client to operate on their behalf, it can get pretty blurry which agent is making the request. Why the client who actually performs the request wouldn't be considered the agent here?
This gets further blury with this statement in https://w3c.github.io/lws-protocol/lws10-authn-ssi-cid/#abstract

This document defines an authentication suite for the Linked Web Storage (LWS) protocol, enabling clients that are able to sign their own identity tokens to integrate with LWS.

Would in that case the agent be the client and if end-user delegates to agent the end-user would be the part of environment? I would find it easier to follow if we pick 4-5 common variants and show how this approach would work for all those variants.

[uvdsl]

@elf-pavlik, I prefer not to make statements about how other models may facilitate certain use cases.

Proposed Model
My proposed model is in-line with NIST SP 800-162 where there exists the distinction between Subject and Subject Attributes. My proposed model subsumes NIST's Subject Attributes, Object Attributes and Environment Conditions into my model's environment. It thus maintains NIST's distinction between the Subject and "the state of the world" (i.e. the environment).
The proposed model is also in-line with WAC's current model, maintaining to define the subject of an authorization.

If the proposed model does not align with your mental model, it does not mean that the proposed model cannot facilitate your use cases nonetheless.

Use Cases
Your proposed use cases on attribute-based access control using VCs or UMA claim pushing are supported in this model using particular conditions (to be defined).

The use case for delegation is indeed interesting, and the distinction between authorization subject and environment helps here: The subject is the delegate, i.e., the one accessing a resource on behalf of the principal.
Even if the agent identifier of the subject is not hardcoded into an authorization rule (e.g. use acl:AuthenticatedAgent instead), a condition may apply stating that the principal must have delegated permission somewhere in the environment (which can provided by the delegate during authentication e.g. via sub (principal) and act.sub (delegate) using RFC 8693). This of course opens the can for impersonation which we do not need to go into detail here (happy to discuss elsewhere) because impersonation cannot be protected against by any access control language.

The question whether a client can be an agent is orthogonal to the here proposed model for conditional authorization. The proposed model allows for both options.

[elf-pavlik]

NIST SP 800-162

There are characteristics or attributes of a subject such as name, date of birth, home address, training
record, and job function that may, either individually or when combined, comprise a unique identity that
distinguishes that person from all others. These characteristics are often called subject attributes. The
term subject attributes is used consistently throughout this document.

[...]

Environment conditions are dynamic factors, independent of subject and object, that may be used as
attributes at decision time to influence an access decision. Examples of environment conditions include
time, location, threat level, and temperature.

[...]

Like subjects, each object has a set of attributes that help describe and identify it. These traits are called
object attributes and are sometimes referred to as resource attributes. This document uses the term
object attributes consistently throughout. Object attributes are typically bound to their objects through
reference, by embedding them within the object, or through some other means of assured association such
as cryptographic binding.

Why something like client or issuer would be environment conditions? They don't seem independent form the subject since subject is using the client and claims identity that can be verified by the issuer.
Would it matter here if resource/object owner/controller mandates specific client and/or issuer, compared to RO leaving it undefined and subject/requester freely choosing which client and issuer they will use for given request?

If we look at examples with age verification or organization membership credentials. Those seem to me like attributes of the subject not environment condiotions. Note Affiliation in this figure:

ACLs and RBAC are in some ways special cases of ABAC in terms of the attributes used. ACLs work on
the attribute of “identity”. RBAC works on the attribute of “role”.

Identity verified via ID Token or role verified by a MembershipCredential both seem to me like attributes of the subject, and not "dynamic factors independent of subject and object".

Policy is the representation of rules or relationships that makes it possible to determine if a requested
access should be allowed, given the values of the attributes of the subject, object, and possibly
environment conditions.
Environment conditions: operational or situational context in which access requests occur. Environment
conditions are detectable environmental characteristics. Environment characteristics are independent of
subject or object, and may include the current time, day of the week, location of a user, or the current
threat level.

So far we miss object attributes, I think a common one would be often discussed creator, if subject created a resource/object it can have specific access. There is also usecase in old authz panel UCR - Conditional access by time which is a good examle of dynamic env condition - current time. Another use case that I can reall was to update comment only up to 5 min of creation. This one would have both object attribute - creation time and env attribute - current time as of request.

Why not simply define rules based on all possible attributes rather than trying to separate environment conditions?
I think main disctinction for where the attribute belongs might be who can assert that attribute and how it can be verified.

Where ID Token asserts identity attribute, poilcy may need to specify if user selected issuer is allowed or RO only allows specific issuer(s). Similar may apply to age verification, membership etc. So issuer seems to be a special (meta?) attribute here rather than subject attribute or env condition. Who can assert age - issue valid credential?

In Solid-OIDC the same issuer asserts client identity attribute. As captured in solid/specification#517 RO may not accept it and require that Resource AS asserts client identity, for example by AuthN on token endpoint.

[elf-pavlik]

3.1.3.5 Environment Condition
Environment condition refers to context information that generally is not associated with any specific
subject or object but is required in the decision process. They are different from subject and object
attributes in that they are not administratively created and managed, but instead are intrinsic and must be
detectable by the ABAC system. Environment conditions such as the current date, time, location, threat,
and system status, usually are evaluated against current matching environment variables when authorizing
an access request. Environment conditions allow ABAC policies to specify exceptional or dynamic AC
rules that cannot be described by subject/object attributes only. When composing ABAC rules with
environment conditions, it is important to make sure that the environment condition variables and their
values are globally accessible, tamper proof, and relevant for the environments where they are used.

Based on this section I think from the use cases discussed so far maybe only the 'current time' would fit under env condition. All the rest looks to me like subject(s) and object(s) attributes.

3.2.2.2 Identity Management Integration
A request for access to an object must be authenticated as originating from a unique subject.
Authentication is achieved through use of identity credentials, and must occur before an access decision
can be made. The ABAC system needs to support the prevalent and strategic authentication mechanisms
and credentials used by the organization. This may mean the organization needs to make enhancements to
its authentication infrastructure, if its current state impedes ABAC adoption. The subject attributes
conveyed in these credentials should uniquely determine the subject, and the identity vetting process used
to issue credentials should be sufficient to hold the identified entity accountable. The issuance and vetting
processes should be recognized throughout the enterprise as trustworthy and sufficient to enforce
accountability requirements.

I think I better understand your suggestion to use acl:AuthenticatedAgent 👍
While it would be nice to have to generalize agent identity as subject attribute, I also see benefit with working around the social graph where peers have strong identities. At the same time other people may prefer identifiers that can't be corelated, for example this exploration - https://kushaldas.in/categories/web.html

I'm happy to focus on cases where the authorization system can rely on identities of peers in our social graph and put other scenarios aside, at least for some time. In SAI, besides the end user / requesting party / requester the data owner/controller is also very prominent and clearly situated in user's social graph.

Finally, looking at 3.1.2.5 Enterprise Governance and Control - specifically ACL Trust Chain and ABAC Trust Chain, I think that we may be facing deeper and longer conversation while looking how to adpot things from this Guide to ABAC.

---

I think it may be worth to anwer how much of this conversation is related to broader

• Towards an authorization framework for the Solid ecosystem authorization-panel#121

And how much on the other side of the spectrum, related to Solid 26?

Thinking of Solid 26 and what's currently implemented and deployed. Solid-OIDC has an issuer which asserts both agent and client (azp) in the ID Token (still mostly global access token out in the wild). With that in mind, I think for Soild 26 we may just need something that matches that state of things. It might be worth considering to simply define a shape that would restrict Authorizations with solid26:Authorization, solid26:agent, soild26:client, solid26:issuer and anticipate that eventually it will be replaced with solid28:Authorization which may or may not reuse some of solid26: predicates. I wonder if we want to spend another 10 years trying to design future proof system which has hardly any actuall use or do 5x 2 year long iteractions where we try things, break things and keep getting better as we iterate on various solutions. To my understanding Solid 26 will be communicated clearly as ~ year of stability with heads up that things will be changing.

[uvdsl]

Thank you for your thoughts. Let me clarify a few points where I think there might be a misunderstanding.

The proposed model does not (try to) implement NIST SP 800-162.
The proposed model is in-line with NIST, meaning that it supports NIST's model and is not contradictory.
In particular: proposed model's notion of environment $=$ NIST subject attributes $\cup$ NIST object attributes $\cup$ NIST environment conditions. As I said before, the notion of environment subsumes these elements, meaning that you can define conditions on any of those three NIST categories in the proposed model.
The proposed model does not need to cover all of NIST explicitly (e.g. enterprise section -- which may be supported in the model through specific conditions); it just takes NIST as a grounding where necessary and helpful.

The discussion about whether NIST's general framework is "the right" authorization framework for Solid is orthogonal to the discussion in this PR, which focuses on extending WAC with required and desired functionality of conditional access (be it client, issuer, or time).

On acl:AuthenticatedAgent, I am under the impression that you assume that use of this term entails that the WebID of the agent MUST become known to the access control system during authentication. This is not necessarily the case, a pseudonym is sufficient according to the term's definition. Moreover, a pseudonymous agent remains effectively anonymous if the pseudonym is only used once (formal security property: unlinkability), meaning that anonymous access after authentication is also supported by this term. This is also in-line with the general definition of authentication as a formal security property: Also anonymous agents can be authenticated. Our work on RDF-Based Semantics for Selective Disclosure and Zero-Knowledge Proofs on Verifiable Credentials enables such use cases for RDF-based attestations. I am happy to discuss details on the solution to this use case elsewhere.

[elf-pavlik]

Thanks!

Currently I think Option 2: Terms for Intent looks to me like a safer approach.

If we consider conditions to also include subject and object attributes. Doesn't acl:agentGroup and acl:agentClass also have conditions? Looking at acl:agentGroup it looks to me that

• the denoted group is the authority to assert gruop membership attributes for subjects/agents
• agent/subject/requester has to have attrivute of membership in the denoted group

Which in practice leads to the common issue of authorization systems not being able to check this condition unless the group membershipt listing (the authority for agent attributes) is public readable.