SPI - Authorisation to access detailed station and programme information

[Nick Piggott]

Ben previously discussed a proposal to add an api-key to requests for SPI information, which would allow the broadcaster to provide more detailed information to known clients.

This proposal has been turned into a draft addition to TS 102 818, as section 10.5 "Client Identification and Customised Response". The text of this is attached as a PDF file.

Please post your comments or proposed changes here by 29th April 2016. After this date, if there are no proposed changes, we'll put this forward for editorial review and submission to ETSI as an update to TS 102 818.

Nick

Project Director

[Andy Buckingham]

As the spec states this is not for authentication, purely for client (or possibly client “class”) identification, you could potentially use a User-Agent string for a similar purpose. However, the usage of this header becomes increasingly complicated when developing on top of third party platforms and HTTP library implementations that restrict the modification of the UA string, so explicitly defining a new key/value pair for this purpose seems wise.

I do wonder if using the term “API Key” confuses the issue of it not being an authentication method? May I propose changing this to a term such as “Client Identifier”, which hopefully reduces the risk of confusion.

It then might also be worth adding a clarifying note that appends the existing explanation that it’s not an authentication method and instead “identifies a client *OR* grouping/product range/class/family of clients”, to drive home the understanding that it’s not intended to be a traditional one-to-one token type value for an individual instance of a client.

Additionally, do we need to specify valid/invalid characters and a maximum length for the value? The encoding can be inferred via the HTTP spec, but it does not specify a maximum length for headers (though some servers will throw a 413 error if you send a request with headers above 4KB in total). 255 characters maybe?

Andy.

> --
> 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.
> <ETSI TS 102 818 v3.1.2 New Section 10.5 on API Keys.pdf>

[Nick Piggott]

So you can get a better idea of why we're suggesting this addition, here's a some background.

The current SPI standard allows a great deal of meta-data to be held in the various documents - SI.xml and PI.xml. Most of this meta-data is fairly obvious, but there are some elements that broadcasters need to control distribution of.

Examples of elements that broadcasters want more visibility of use are:

* URLs for live streams - in some cases, broadcasters have complex business rules around streaming use

* URLs for on-demand content - often there are rights managements controls required

* Detailed synopsis, including images - this data may need to be presented and credited in a certain way

What we are proposing to add is the optional ability to provide this level of detail only to clients who have agreed to use it properly. That probably means signing a Terms and Conditions or Acceptable Use agreement with the broadcaster. Once that agreement is in place, the broadcaster can provide a unique key value, which is used to identify that user (or their client devices).

We don't specify in this standard whether user means "end-user" or means "intermediate company". So a manufacturer might sign the agreement to cover all the devices they make, or an app developer might sign one for each end-user. We haven't presumed anything.

This is all optional. If the client doesn't provide a key, or the broadcaster doesn't want to support them, the client should still get the data that the broadcaster is prepared to publish openly (which will usually be to our Project Logo specification).

We also are not suggesting that RadioDNS gets involved with creating or signing agreements, as that's not part of our mission. We can look at how we can help manufacturers and broadcasters contact each other to agree terms and exchange keys, but we won't be a party to any of those agreements.

If you've got any questions, post them here, or email us in the project office on feed...@radiodns.org

Nick

[Nick Piggott]

Hello,

A reminder that we have passed the deadline of 29th April 2016 for comments on this document.

Unless anyone provides comments in the next 24 hours, this amendment will be put forward as a formal change to TS 102 818.

Best regards

Nick

On Thursday, 24 March 2016 19:27:50 UTC, Nick Piggott wrote: