The party being delegated to is unspecified

[selfissued]

https://www.w3.org/TR/2024/WD-controller-document-20240817/#capability-delegation
The description doesn't say how the capability being delegated is represented. For instance, how does a developer know to which HTTP API authority to access is being delegated?

[msporny]

The specification is agnostic to the capability scheme... could be Authorization Capabilities, could be UCAN, or something else. The spec shouldn't specify how capabilities are represented; it's intended to be a generic mechanism.

[selfissued]

The capability being generic doesn't relieve us of the responsibility to readers to say how to use it.

Even an example or two could help make this less opaque.

[decentralgabe]

I agree with an example or two to demonstrate usage of the property.

[msporny]

Just to be clear, you two are asking for an Authorization Capabilities (ZCAP) example and a UCAN example and won't object once we put those examples and references in the specification?

[decentralgabe]

@msporny I won't object as-is; however, I think for all the properties the spec enables, providing examples is useful. This is true for some other issues Mike opened too (there may be more):

• Authentication verifier definition missing #62
• Delete misleading text about possible purposes for authentication #60

[selfissued]

Building on my suggestion for #61, maybe say "The processing performed following delegation is application-specific."?

[TallTed]

I agree with an example or two to demonstrate usage of the property.

It must be made clear that such examples demonstrate that "uses include, but are not limited to..."

[msporny]

In order to make progress at W3C TPAC, I am suggesting that this issue is "editorial" and can be resolved during the Candidate Recommendation phase. The VCWG will discuss this issue at W3C TPAC to see if the "during CR" determination is correct.

[msporny]

PR #123 has been raised to address this issue. This issue will be closed once PR #123 has been merged.

[msporny]

PR #123 has been merged, closing.