Identifying Streams by Authorization Token
Issue #7
new
In order to have a single endpoint for all streams at a transmitter, an assumption is made that issued oauth tokens are used to identify identify individual streams.
The specification suggests no process for obtaining such token. The suggestion was made that the OAuth scope parameter could be used for this purpose. The OAuth community has indicated several times that this is not the intent of the OAuth scope parameter. As of now, OAuth has no standard model for requesting access to a specific document or resource. A proposal put forward suggests how this might work was not adopted (from Brian Campbell and expired May 2017): https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
Impact: If administrators have to obtain access tokens by hand, the value of the management API is undermined. Why not configure by hand too?
There is a security risk if administrators are handling access tokens directly.
Requirement: The Management API needs to allow for and enable unique stream URI paths.
Comments (8)
-
-
reporter
How does this work when the IDP is an SMTP server? Where is the oauth infrastructure?
How does this work at RP sites. Where is there OAuth infrastructure. They are clients to OIDC, they are not issuers.
So far, the RISC participants have only considered the IDP as master and god in the scenarios. Events flow from RPs and from implicit IDPS have not been considered.
-
If a party is exposing an API, they will need some mechanism to authenticate callers and manage authorization. While the party may not have an existing OAuth infrastructure, they will need some infrastructure. If we let them use any infrastructure, then we put the burden of supporting any infrastructure on all the participants. By specifying OAuth, all parties have a common infrastructure which lowers the overall burden. Yes, this will require parties to implement an OAuth infrastructure if they don't have one, but that seems more desirable than forcing all parties to implement a wide variety of infrastructures.
-
reporter
These are operational decisions. I do not believe they belong in the standard. I suggest the the risc profile document be an operational document and not a normative document.
To over specify would block utility. For example I have pointed out that FAPI members could not adopt since they require POP tokens.
What i am trying to avoid is future forking of secevents and risc. Normative authen requirements would force FAPI to copy and incompatibly alter RISC.
As an example, ietf differentiates between standards and best practices. I would call the risc profile a best practice, but it is likely even more subject to operational change requiring a more agile lifecycle than normally tolerated by standards.
Phil
-
Just because FAPI requires POP for the FAPI specification does not mean they can't use OAuth bearer tokens for RISC. FAPI and RISC are not the same thing.
Specifying how APIs authenticate improves interop, and is what the RISC WG has decided to do. Your dissent is noted, but time to move on.
-
reporter
The chair should make a consensus call.
Phil
-
Phil, the requirement you put forward, "The Management API needs to allow for and enable unique stream URI paths", and the title of this issue do not quite match. "Identifying Streams by Authorization Token" is one possible solution.
At the previous two face-to-face meetings we looked at multiple vs single streams between a given transmitter and receiver, and here I think this is the core issue. Let's step back and look at all the options.
The use case we are trying to address (as far as I know) is for a receiver to outsource some of its services and then the need to send parts of the streams to other providers (auditing, abuse, etc). Do we agree on this?
Here are solutions for that use case:
A. Management API that allows creation of multiple streams (hence unique stream paths or identifiers).
Having multiple streams delivering to different endpoints (through different methods) while solves the splitting of the stream, it is not solving the authorization delegation issue. The provider that provides abuse services, will not only have a blind endpoint that receives events, it also needs to access the transmitter exposed API to check status and such. How is this provider going to get authorization? Furthermore, the provider might want to change its endpoint, should the provider have access to stream configuration? How is the provider going to coordinate stream updates with all its clients (receivers)? If a provider has a bug, let's say, and it overloads the transmitter (by sending corrupt access tokens for example, or too many requests), since the transmitter cannot differentiate at the authorization level between the receiver and its multiple providers it might disable the whole receiver and now all providers offering a service for a given receiver (including the receiver itself) will have an outage.
B. Management API that allows only one stream (as currently defined in the RISC Profile).
B.1. Multiple streams implicit based on authorization, and authorization out of scope.
As proposed by Dick, there are cases where this approach would work. We went through one of these cases in detail in Singapore. It was the OP as a service case presented by Mike.
B.2. Explicit delegation model.
Instead of the receiver creating multiple streams, the receiver has an API to create explicit delegation for its one stream.
The API allows the receiver to specify that it wants a set of its events to be delegated to another receiver. Service providers will have to register as receivers with the same transmitter, and they will each have their own stream, and own authorization credentials. Everything is cut and clear, the transmitter can identify each individual service making calls, the receiver does not have to pass authorization tokens to its providers, providers have full control over the configuration of their streams.
Another advantage of delegation, each provider deals only with the level of complexity they have to. In most cases single stream and no delegation is enough, no extra complexity. Cases that need to split streams will have to deal with the extra complexity.
Basically, each entity that receives events has one stream and each receiver has an API to create one or more delegations (as opposed to one or more streams).
B.3. Receiver implements a dispatcher.
We talked about this quite a bit. No spec support, receivers have to split streams on their own, they become transmitters for their service providers.
I don't think we should argue over single vs multiple at all. Single and multiple is also an option, we can have two management APIs, but I think delegation is a much better model than multiple streams. Let's get back to use cases and see how we can solve them,
-
I started implementing this and I also got this roadblock on how to identify a stream uniquely. Is this issue came to a conclusion?
- Log in to comment
There are numerous ways to obtain access tokens. For 3P service providers, one of those flows could be a 3 legged OAuth flow from the RISC SP to the transmitter so that they RISC SP obtains a authorization code for the "receiver" from the transmitter. If the receiver wants to also have a separate stream for the same data, then the receiver can obtain their own access token.