About claim "aggregation_uri"

[Denisthemalice]

In #228, C2bo wrote:

The claim "aggregation_uri" is meant as a way to allow efficient caching for RPs, not for alternative URIs - it points to all relevant status lists for an issuer or specific referenced token type.

"aggregation_uri" is defined in 4.1 as:

aggregation_uri: OPTIONAL. JSON String that contains a URI to retrieve the Status List Aggregation for this type of Referenced Token.
See section Section 9 for further detail.

Section 9 (Status List Aggregation) states:

Status List Aggregation is an optional mechanism to retrieve a list of URIs to all Status List Tokens, allowing a Relying Party to fetch
all relevant Status Lists for a specific type of Referenced Token or Issuer.

These two descriptions are not aligned with section 4.1, as in section 9, the sentence mentions:

all relevant Status Lists for a specific type of Referenced Token or Issuer.

The case of the Issuer is not mentioned in section 4.1.

Then comes some questions.

How can the Relying Party retrieve either:

a) all relevant Status Lists for a specific [type of] Referenced Token, or
b) all relevant Status Lists for an Issuer ?

In the first case, how long should "all relevant Status Lists" for a specific type of Referenced Token be accessible ?
Same question for "all relevant Status Lists" for an Issuer.

There should be some additional text to warn the Issuers about some consequences when this claim is supported.

"All relevant Status Lists for an Issuer" allows a Relying Party to know how many Referenced Tokens have been issued by an Issuer and are either valid, suspended or revoked at an instant of time. This reveals the number of entities that have been registered. Some Issuers might not like to disclose that information and should be warned of the consequences before choosing to support this optional claim.

Finally, I still have difficulties to understand the usefulness of this optional claim for a Referenced Token.
Caching is pretty well supported by the ttl claim:

• ttl: OPTIONAL. The ttl (time to live) claim, if present, MUST specify the maximum amount of time, in seconds,
  that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved.

[paulbastian]

Editors Call:

• we will fix Section 4 to add ".. or Issuer"
• the privacy consideration that you mention is already present in the draft: https://drafts.oauth.net/draft-ietf-oauth-status-list/draft-ietf-oauth-status-list.html#section-12.4