Authorisation for documents

[Ben Poor]

Dear All,

Traditionally, feeds of RadioEPG metadata have been implemented in order to serve the same documents to all clients. However, as we move forward with more Broadcasters and Devices supporting the standard, different models will inevitably be required.

The specification has long been open to the concept of tailoring a response to a request, in order to return a *more appropriate* response. However, there is now a requirement to provide methods by which *specific clients* may be identified.

One motivation for this is to allow Service Providers more control over their metadata, if they wish. They may wish to only provide certain types of metadata to clients who are covered by prior agreement. The agreement process would be a step in being provided with a means to access the data.

I'd like us to explore ways and methods in which clients can be identified, and how this would work with a RadioEPG service, while still keeping a 'public' feed for those clients who do not wish to be identified.

Ideally, this would use technologies and methods which are widely-supported and lightweight. For example, through using an API key:

1. Service provider issues client with an API key

2. Client will use the API key in requests for RadioEPG documents, all of which shall be done using HTTPS

3. Any unauthorised requests will be returned with the appropriate HTTP response (401, I suspect).

I'd like to come up with a set of steps like the above that can be put in the specification as a behavioural framework. The exact implementation details (i.e. how the API key is issued, managed and expired) would be out of scope and up to the Service Provider to manage.

I'm hoping we can get a good discussion going on this fairly rapidly, so please send me your thoughts.

Ben.

[Ben Poor]

All,

Just a reminder that I'm keen to get feedback on these ideas at the soonest opportunity.

If you're a Broadcaster - do you have challenges with a completely open RadioEPG feed?

If you're a Device Manufacturer or Aggregator - how would you cope with different authentication models when trying to access data?

Anyone else - are there any good models of providing light, optional, authentication/authorisation?

Please either post back a reply to this thread or just to me.

Ben.

[Andy Buckingham]

Hi Ben,

As a developer for service providers I can appreciate the desire the control the release the control of metadata in certain situations.

Rather than encourage the creation of new, alternative standards for secure meta delivery - a simple acknowledgement of the ability the secure the acquisition of EPG over HTTP through one or more undefined security mechanisms in the specification is a good idea.

I think the key to this is not to choose a single security mechanism (e.g. OAuth) but leave the spec open as you suggest. Each technique varies quite considerably with a lot of technical detail and the space can often be fast moving. Is it worth possibly including a list of suggested mechanisms (at date of publication) with references to their respective spec documents? Ideas that immediately spring to mind...

* OAuth2

* EBU Cross Platform Auth (CPA)

The only clarification I'd suggest to the initial steps you propose, in Step 3 is it worth more clearly defining that it's OK to return different documents based on the absence of a token/security provision rather than a simple "secure or 401" implementation? For example, a service provider may want to return only broadcast bearers on their service information document for unsecure/anon clients. However, with the presence of a "Authorization: Bearer <TOKEN>" (OAuth2) in the request headers, the service information XML also includes IP bearers. A 401 would never be used in this circumstance.

The one drawback of not explicitly defining a single security method in the spec is that this won't allow inter operable implementations of secure EPG acquisition for device manufacturers. In that example the manufacturer would have to look in to the security provisions of target broadcasters and ensure their implementation works with them. I don't see this being of too much concern as primarly I suspect the desire to restrict access to metadata in certain situations is driven by the use of the data by aggregators as opposed to devices themselves, so the anonymous/unsecured access to EPG can still work as normal. Should SPs and manufacturers look to use security on broadcast-to-device exchanges, this could be driven by market adoption and consumer demand - but it's worth noting as a concern.

Andy.

On Tuesday, 6 January 2015 16:21:35 UTC, Ben Poor wrote:

[Barroco, Michael]

Hi Ben,

As Andy suggested, we have an EBU group working on how to authenticate requests from media devices. We published in September an EBU Recommendation called The Cross-Platform Authentication protocol: https://tech.ebu.ch/docs/tech/tech3366.pdf

The group is open to everybody: https://tech.ebu.ch/cpa

Here is a presentation from Sebastien Noir (RTS, Swiss public broadcaster):
https://tech.ebu.ch/docs/events/devcon14/presentations/09%20EBU%20DevCon_CPA_Sebastien%20Noir.pdf


It is based on OAuth2.0 concepts with a focus on media environments.


The current objective is to go to ETSI before the end of the year and my understanding is that the next version of RadioTag will include CPA as authorization mechanism.

I would be delighted to provide more information if you want.

Kind regards,

Michael





From: radioepg-...@googlegroups.com [radioepg-...@googlegroups.com] on behalf of Andy Buckingham [andy.bu...@togglebit.co.uk]

Sent: Tuesday, January 13, 2015 9:49 AM

To: radioepg-...@googlegroups.com

Subject: Re: Authorisation for documents

--

You received this message because you are subscribed to the Google Groups "RadioEPG developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to

radioepg-develo...@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout.




------------------------------------------------------------------------------

**************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the system manager. This footnote also confirms that this email message has been swept by the mailgateway
**************************************************

[Sebasti...@swr.de]

Hi Ben,


Sorry for the late response. From my public broadcasters pov we have no
challenges with a completely open EPG feed.


However if so, what about providing a dedicated https-URL to the client
with whom a service provider may have an agreement.


Best
Sebastian

[Walter Huijten NPO]

Hi all,

As a broadcaster obviously I would like to have my metadata published as widely as possible, so a completely open EPG feed is my preference.

However I am triggered by Ben's phrase: "...to allow Service Providers more control over their metadata...". This is a little too abstract for me. Can you please describe a specific Use Case to me where this would be required?

The only one Use Case relevant to me that comes to mind is that I might want to offer different streaming urls to e.g. TuneIn versus vTuner. But as we discuss this further other uses might become apparent.

Walter

Op dinsdag 6 januari 2015 17:21:35 UTC+1 schreef Ben Poor:

[Ben Poor]

Dear All,

Thanks for all the thoughts and comments - its great to hear from Broadcasters and Service Providers. I'd be very interested to also hear the thoughts of Device Manufacturers, so I'll try and tie up some of the threads here.

I think Andy gave a summary of this: "a simple acknowledgement of the ability the secure the acquisition of EPG over HTTP through one or more undefined security mechanisms in the specification is a good idea."

Its something we haven't discussed previously, and its about defining the 'right place' for this to happen, should it be needed.

As a few people have observed, I think the most obvious use-case here is between a Broadcaster and an Aggregator. 

Lets say a Broadcaster already provides an open RadioEPG feed to the world. They then enter into an agreement with a specific Aggregator that states they will add additional information to the feed they provide purely to that Aggregator. 

This could be for any number of reasons, and could result in richer metadata, or metadata within a specific namespace for that Aggregator (i.e. something that can't be accommodated by the core namespace). Or, as Walter suggests, returning a different streaming URL based on the Aggregator making the request (e.g. TuneIn, vTuner, etc.).

They would then negotiate an agreement with the Aggregator that results in them being given a key that they would use in any requests for RadioEPG documents. 

My proposal is that we put a section in the specification that explains *where this key should go*. I would purposely not go into detail on *how that key is acquired*. I would determine that to be out of scope - as Andy mentions, the ways in which keys may be acquired will change rapidly. Certainly things like CPA and OAuth2 are good suggestions on how clients may acquire a key.

I definitely agree that a Service Provider should be able to decide whether to return a 401 code or a generic RadioEPG document when the authorisation has failed. 

Also, for the purposes of these discussions, when HTTP is mentioned this includes the use of HTTPS. Again I would propose we put in the specification that any document requests including keys *must* be in HTTPS. I can't think of a reason why we wouldn't mandate that (discuss).

It would be useful for me to sketch out some further use-cases so we can visualise them, which I will do, starting with the ones Walter and myself have already proposed. If there are any specific ones you can think of, then please let me know.

From what I've heard so far, it sounds like there are no objections in principal to making this kind of change to the specification, albeit with the note that its not something that most Broadcasters would wish to do at this time. Again, let me know if I've not read that correctly.

As always - more views appreciated! I'll try and reply quicker next time.

Ben

[Ben Poor]

Dear All,

Picking this one up again after a long absence. 

As mentioned in my last email, I haven't received any objections to this proposal, so I shall be making a formal request to add this functionality to the specification, on behalf of the RadioEPG application group.

The language of the proposal has not changed - we are specifying how an auth key will be included in HTTP requests and *not* how the auth key is originally acquired. The actual content of this proposal will be a short paragraph and perhaps an example.

I intend to make this request in the coming weeks, so please let me know if you have any additional feedback/concerns about this.

Many thanks

Ben