"supported_scopes": Meaning of multi scopes and switching from endpoints to logical names

In the server discovery endpoint the following is specified:

supported_scopes

OPTIONAL. A list of OAuth {{RFC6749}} scope names that the Transmitter supports for specific endpoints. The value of this >field is a JSON object that has the endpoint names as keys, and arrays of scope name strings they support as their values. >OAuth tokens obtained using any of the scopes defined here MUST be accepted by the specified endpoint. Any key that is not >defined as an endpoint in the Transmitter Configuration Metadata MUST be ignored. If the supported_scopes member is >present in the metadata and an endpoint is not listed as a key, then that endpoint MUST not require OAuth for authorization.

Question 1: When more than one scope is specified, does that mean the endpoint MUST accept any scope value specified, or must all values be specified? I think it should be any one value (an implied OR). This allows for things like differentiating between admin (ability to create a stream) vs. "stream" which might only allow stream update operations but not the ability to create or delete.

How would we indicate read-only, vs update config, vs. life-cycle for the stream endpoint? Do we care?

Question 2: How do we authorize for logical or dynamic delivery endpoints (e.g. /poll/1234 or /events)? These are not necessarily fixed endpoints. Maybe we should switch to a logical names for the map:

"supported_scopes" : {
    "CONFIG": ["admin"],
    "CONFIG_UPDATE":["admin","stream"]
    "STATUS": ["stream"],
    "SUBJECT":["stream","subject"],
    "DELIVERY":["stream","events"]
}

In the above CONFIG allows a client with admin to allow full CRUD on streams. CONFIG_UPDATE would only allow Read and Update on streams for either admin or stream scoped requestors.

In the current spec, I am not sure that assigning different scopes for addSubject and removeSubject is really needed. Nor does it necessarily make sense to differentiate scopes between polling vs. push endpoints (hence "DELIVERY")

Use Case: In general I am thinking there may be administrative systems taking actions separately from "worker" servers that do the event transfer. The scopes are such that a worker can have event only or also be allowed to update status and or events requested. So a minimum priv for event transfer for would be "events", a transfer system needing to be able to update status would want to ask for "events" and "subject". And so on.

Question 3: Should there be a scope allowing access on all endpoints? E.g. "ALL":["root"]
Not saying this has to be implemented, but if it was desirable this is how you would specify it.

openid / sharedsignals

"supported_scopes": Meaning of multi scopes and switching from endpoints to logical names #118