Tagging authentication and syndication solution

[Andy Buckingham]

It's quickly come to my attention that the core issue around RadioTAG
is currently the one around device authentication and tag syndication.
I'd like to abstract this slightly from specific technical detail on
exchanges between client and server and look at the key concepts a
little further.

I believe a typical user journey should be something like:

1. User purchases a new radio and uses it to start listening to radio services.
2. When the user hears something of interest they hit the 'Tag' button.
3. At a late point the user can review those tagged events in a
'Recent Tags' list on the device.
4. The user later wants to view their tag on another device (such as a
laptop or mobile phone.) They visit the website of one of the tagged
radio services where they can see all the tags they have made, both
for that radio service and other radio services.

I believe the current requirements, therefore, to be as follows:

* A user wishes to use Tagging "out of the box" by selecting a service
and tagging straight away
* A user would prefer a minimal and simplified set of registration
steps to be able to view the tags against a service
* A user would prefer to not have to register their device with every
service provider whose content they consume
* A user is most likely to want to view all their tags in a single place

* Service providers may not want to establish a concentrated point of
control (aggregator) and therefore lose visits to their own websites
* Service providers would prefer not to increase costs to be involved
in RadioTAG by funding the uptake and management of a centralised
database solution

* RadioTAG's management body would prefer to not have the overhead and
legal implications of managing a system that may include the store of
personally identifiable data

In turn this raises the following questions:

1. How does a user tell a radio services website that they own a
particular device and want to see their tags for it?
2. How do we ensure the tagging procedure has suitable steps in place
to prevent spamming or being exploited?
2. How do any of the service providers' websites know about each other
and the tags they have also received for the same device?

Therefore, we need to find an authentication process that is
decentralised, simple for the user to follow, doesn't require hoops to
be jumped through for every other service they wish to tag against and
allows different services providers to exchanges tagged information.

If any of this doesn't make sense then please do let me know and we'll
try and clarify the requirements and use case more clearly so that we
all understand the problem so we can then look forward to potential
solutions.

Andy.

[A. F.]

Let's look at this for a second from an abstraction, the abstraction of messaging.

In messaging every resource is an ID. And any ID can send a message to another ID.

For RadioTAG we have 4 IDs so far: a DeviceID, a UserID, a ServiceID and a ProgrammeID (or station ID).

A ServiceID is the server collecting and storing the tags and handling registration. We seem to agree that we do not want a single centralized server nor a completely fragmented solution where every broadcaster has to run its own service.

So let's say we have a couple of ServiceIDs running. A user has to register an ID with a server of his choice. 

Now, there's more than one way to model tagging with the messaging abstraction. For instance, a tag could be a message from

a) DeviceID -> UserID

b) UserID -> ServiceID

c) UserID -> ProgrammeID

c) is probably the best way, but it means that a station has to register a StationID with a service provider too. (the StationID being published via RadioDNS then).

This model solves two problems:

1) how can a user see all his tags?

answer: it's all his "sent messages" on the ServiceID

2) how can a station see all its own tags or tagged content?

answer: by looking at it's "received messages" on the ServiceID, the tags are owned by the station and in no way shared.

So on all my RadioDNS enabled devices, I'd just have to store my UserID locally. The DeviceID could still be used for spam prevention. (The ServiceID would have to force a coupling of USerID and UDI and check the authentication token (DeviceID) for every tag).

I know I sound very "Jabbery" for a RESTful http protocol. Let me know if the abstraction is helpful, I don't want to make this mail too long for the moment.

André,

Basel, Switzerland

[Andy Buckingham]

Thanks for this André, it provides a very different way of looking at
the situation.

> A ServiceID is the server collecting and storing the tags and handling
> registration. We seem to agree that we do not want a single centralized
> server nor a completely fragmented solution where every broadcaster has to
> run its own service.

I don't think we agree that it's totally out of the question for each
broadcaster to run their own tagging system, we just need to ensure
that setting up the device on service providers website is as simple
as possible.

> So let's say we have a couple of ServiceIDs running. A user has to register
> an ID with a server of his choice.

A few questions regarding this; who is expected to run these user
registration services? How will they all be advertised to devices? I
am a little concerned that this adds a further step beyond what was
previously prescribed in that the setting up of a device would require
the selection of a middleman "registration point". We must keep in
mind the lowest possible profile device (something like a 16
character, 2 line LCD display with limited control buttons) and how we
could implement this on a device like that. This may add to listener
confusion explaining a 3rd party sits in the process between device
and broadcaster and how you tag. We also have to consider the affect
this has on data protection.

A

[Andy Buckingham]

Having had a bit of a brainstorm this afternoon, I'd like to propose
some tweaks the existing methodology which incorporate some ideas
already thrown up in this thread.

Here is an alternative user flow:

1. Out the box a radio makes its first tag to any particular
supportive broadcaster. This exchange includes UDI, null API key,
tagged event details and service identification info.

2. The broadcaster responds with a new API key to secure future
communication for the supplied UDI and also a human readable
simplified UDI (SUDI) as per Paul's idea for simplifying setting up a
device on a broadcasters website. However, the twist is that the SUDI
is a composite of 2 components, the first part is a code identifying
the service provider who issued it, the second identifying this
device.

3. When a user tags another service from a different broadcaster, the
device sends the UDI and SUDI with the request. The broadcaster can
then split the SUDI and perform a separate lookup against a central
RadioTAG resource to work out which broadcaster first saw this device.

4. The second broadcaster then contacts the first broadcaster to
request details of any other broadcasters this device has been seen
by. They can then cache this and optionally return it should they too
be queried. We create a distributed knowledge of other known
broadcasters.

This now means we can put our simplified device ID in to any station
website of a station we've tagged against and it immediately knows who
else to contact to get a complete view of tags. Additionally, you can
link multiple physical devices (UDIs) together via a station website
to the same SUDI so that the radio in a bedroom knows about tags made
against other service in the kitchen. We have syndication but avoid
having a single centralised database. We also avoid a scenario where
3rd parties sit in the middle as tag holding houses, the relationship
is maintained between listener and broadcaster.

This is still a slightly abstract concept but I'm interested to see
what people think of this approach? If there is interest I'll try and
scope it more clearly and provide a diagram and examples.

A

[A. F.]

Regarding the SUDI idea: I think this is a technically clean and very democratic solution. 

The benefit for the listener is obviously that he can see all his tags on any broadcasters site.

So my tags are on:

- thisisglobal.com/radiotag/SUDI

- absoluteradio.co.uk/radiotag/SUDI or behind a central login or something similar

BUT:

1) it forces broadcaster to run REST interfaces (every broadcaster has to be able to handle the first registration), plus the cache and the syndication and of course a tag database

2) we still need a central RadioTAG database (?)

I'm really not sure I need all my tags on every broadcaster site. I'm interested in tags "enriched" by the broadcaster, offering me some benefit. And I'm willing to log on a broadcasters site to get those.

From a listeners perspective, it's probably best to keep some things centralized (either a central tag holding house or a central authentication service to check against for broadcasters).

With a SUDI, we're trying to model a central service with syndication. That sounds like a lot of work for broadcasters - will that work?

André,

Basel, Switzerland

[A. F.]

> So let's say we have a couple of ServiceIDs running. A user has to register
> an ID with a server of his choice.

A few questions regarding this; who is expected to run these user
registration services? How will they all be advertised to devices? I
am a little concerned that this adds a further step beyond what was
previously prescribed in that the setting up of a device would require
the selection of a middleman "registration point". We must keep in
mind the lowest possible profile device (something like a 16
character, 2 line LCD display with limited control buttons) and how we
could implement this on a device like that. This may add to listener
confusion explaining a 3rd party sits in the process between device
and broadcaster and how you tag. We also have to consider the affect
this has on data protection.

Registration services could be run by broadcasters or third parties. Advertisement to devices is a problem, yes. As I said, the model is messaging and the keyword to that is xmpp federation. I think it's possible to have a similar federation model for RadioTAG, that's all - and it's actually not that far away from Andys SUDI proposition below.

André

[Andy Buckingham]

> So my tags are on:
>
> - thisisglobal.com/radiotag/SUDI

Not necassarily and this certainly wouldn't be a spec, I think it's
important that broadcasters always try and surface the relationship
between user and tags, rather than device and tags. For any kind of
viewing tag "timeline" should be under a username, e.g.

- http://www.capitalfm.com/tags/andybee/

> 1) it forces broadcaster to run REST interfaces (every broadcaster has to be
> able to handle the first registration), plus the cache and the syndication
> and of course a tag database

Yes, although there is no reason why a third party cannot act on
behalf of another station in some kind of agreement, similar to the
way a number of stations in the UK currently use third party providers
for websites and SMS platforms, for example. You would simply add the
third parties server details to the SRV records in place of the
broadcasters.

> 2) we still need a central RadioTAG database (?)

The only centralised database would be a table that matches a
broadcasters SUDI start code with a server for their version of the
web services. For example, we could piggy back the existing RadioDNS
methodology and add an extra record for known tag service providers,
e.g.:

- c123.tag.radiodns.org --> tag.musicradio.com

> I'm really not sure I need all my tags on every broadcaster site. I'm
> interested in tags "enriched" by the broadcaster, offering me some benefit.
> And I'm willing to log on a broadcasters site to get those.

I believe the thought process behind this is that the user may not
know what the broadcasters website is. For example, if they want to
view a tag they made a few weeks ago they could have forgotten which
station that tag was made against. They could review the recent tags
list on a device, but if they are away from home it may be an easier
user paradigm to just say you can log in to any site of a broadcaster
you've tagged against to gain access to your tags.

> With a SUDI, we're trying to model a central service with syndication. That
> sounds like a lot of work for broadcasters - will that work?

I don't believe it's significantly different to the original model of
a one-to-one tag-to-service provider system, with an additional layer
to tie the services back together?

[Sebastian]

Hi All,

A good discussion and a lot of interesting points here. Thanks for the
different views on the topic ... this is really helpful. Working
through the thread I understood that we have three alternatives
regarding the registration service:

1. central registration using a central RadioTAG-registration-service
2. decentralized registration per every TAG-provider
3. a combination of both ... i.e. syndication-registration

The preferred solution finally should be the one that:
- has a lot of benefits for the listeners (at best: one registration
fits all)
- has a lot of benefits for RadioTAG-providers (at best: aren't
hazzled with any legal stuff or any implementation hurdles)
- has a lot of benefits for the RadioDNS organization (at best: must
do nothing that it fits)

Well, one pillow need to be swallowed ... the most important thing is
that RadioTAG is as easy as possible for the listeners ... which
eliminates option 2.

But if the syndication-registration means a lot of work on the
broadcasters side I'd prefer the central approach (option 1). I'd
guess that the most bugging aspect for RadioDNS would be the hazzle
with legal implications as I assume that the operation of such a
service doesn't require not much money (RadioDNS already has to
operate such a central service).

Anyway ... I'm open to any good solution. But my feeling on the
following:

> Registration services could be run by broadcasters or third parties.

is that the majority of broadcasters don't want to be represented by a
third party that is a competitor. So either the necessary
infrastructure for RadioTAG is set up by their own - or they use a
provided infrastructure from a central (trusted) party.

Would that eliminate option 3 ...!? Not really ... so at the end the
cost-benefit-ratio will make the decision!?


Best,
Sebastian.

[Andy Buckingham]

Excellent points. I'd like to add some points to a few you have
raised, if I may:

> But if the syndication-registration means a lot of work on the
> broadcasters side I'd prefer the central approach (option 1). I'd
> guess that the most bugging aspect for RadioDNS would be the hazzle
> with legal implications as I assume that the operation of such a
> service doesn't require not much money (RadioDNS already has to
> operate such a central service).

Could I just qualify the "lot of work" around the syndication. It
would be an additional web service with an extra table and some extra
logic to operate. My ideal situation with RadioTAG is, once we have
agreed a model, to get a few people to work on library implementations
in common languages (e.g. PHP, Python, Perl, ASP etc.) that do the
vast majority of the web service work. Broadcasters would then be free
to add their finesse on top of these and pipe them in to their
respective website frameworks.

With regard to RadioDNS' centralised service, it is based upon DNS
which offers may benefits in the way of propagation and a relatively
low amount of traffic etc. Also, tagging would involve a lot of user
identifiable data which RadioDNS does not worry about.

> is that the majority of broadcasters don't want to be represented by a
> third party that is a competitor. So either the necessary
> infrastructure for RadioTAG is set up by their own - or they use a
> provided infrastructure from a central (trusted) party.

When I say "third party" I mean a commercial organisation that
provides technology infrastructure for radio stations. A real world
example would be Folder Media who often take the constituent parts -
schedule, music data and "mash" these together to serve RadioDNS
applications for services such as Jazz FM or NME, on behalf of their
operators. In a similar way that radio stations often use third
parties to provide content management systems and hosting for their
websites.

The discussion so far on this topic is excellent, if anyone else has
been lurking and has some strong views on this topic I'd appreciate
getting these out soon so we can start to form a conceptual idea.

[David Madelin]

Matt and I have been discussing Radio Tag in the office and this is how we see a possible solution:

A: Matches UDIDs with Tag Provider
Run By: RadioTAG HQ
A list of authenticated UDIDs paired with who is that UDID's Tag Provider

B: Timestamps and Station IDS
Run By: Any approved Tag Provider (this could be a device manufacturer or a third party)
A list of UDIDs and Timestamps

(the tagging device should be able to show a UDID and also a Keycode - something that a user and an app layer can authenticate against)

C: Application Layer:
Run by: Anyone
Can query (A) and ask who provides the timestamps for a UDID (B). Can then autneticate against B and acquire tags from this provider.

Use Case:

User has an iPhone and a Pure Sensia, both of which he 'tags' on. He wants to use capitalfm.com as the application layer to see his tags.

The iPhone records tags at tags.apple.com and the Sensia from tags.thelounge.com
The user logs on to capitalfm.com and clicks the button marked 'get my tags'
Dialog-box pops up and says, OAuth style:
1. Allow capitalfm.com to collect any tags you make from Capital FM
2. Allow capitalfm.com to collect any tags you make from Capital FM (or its sister stations)
3. Allow capitalfm.com to collect any tags you make from your devices.

User clicks 3.
Dialog asks for UDID and a keycode
User enters code for iPhone.
User enters code for Sensia

Capitalfm.com queries (A) for UDID 0-123-456-789 and is returned with:
0-123-456-789 - tags.apple.com
Capitalfm.com queries (A) for UDID 0-123-456-790 and is returned with:
0-123-456-790 - tags.thelounge.com

capitalfm.com contacts tags.apple.com and authenticates 0-123-456-789 and Keycode
capitalfm.com contacts tags.thelounge.com and authenticates 0-123-456-790 and Keycode

Apple and Pure/TheLounge are required to update capitalfm.com (at intervals?) with UDIDs, Station IDs and Timestamps

capitalfm.com integrates this as a tag list for User.

Killing off the Link.
User sells their Sensia and wants to unlink their tagging.
User can either:
1. Pull up on their device a list of authenticated providers
2. Login to manaufactuer website (with UDID and keycode) to display authenticated providers.
Using either of these they can cancel an Application Layer's authentication

Benefits of this are that:
1. Anyone can run a tag server
2. Anyone can run a application layer
3. All providers must provide Oauth style interoperability
4. Manfacturers can choose to control the tag server bit if they want (a bit like they do with station lists) or use 'someones'
 open  tag server.
5. Minimizes RadioTAG HQ's involvement (in theory RadioTAG could issue ranges of UDID)
6. Users are in control of who can use their personally identifiable data (through the app layer) and RadioTAG doesn't see any of this.
7. The server load is shared between Tag Providers and Application Layer providers.

Downside:
1. RadioTAG still has to do something centrally
2. Device needs to be able to disaplay UDID and a Keycode

David

http://twitter.com/pintofbeer

--
David Madelin

Mobile: +447764 487209

[Mark Glanville]

That doesn't explain quite how data moves around if tags come from
stations other than those owned by the application layer. It's one
thing to collate the tags themselves, but they just describe a
broadcast and a timestamp. The tags need to be combined with
information from broadcasters in order to have any meaning.

Also, while the setup you describe works in terms of a lister who tags
things as they listen and then can recover that information later on,
it doesn't help the broadcasters who could use tags to obtain some
realtime feedback from listeners. Manufacturers aren't supposed to
"hang on to" tags until the user registers the device with an
application layer. They have to pass the tags on to the broadcaster
(via a RadioDNS CNAME/SRV lookup) straight away. The reason for
registration is to link the device to a user for the user's benefit.

Have I missed something? This is a great discussion, but I feel like
we're drifting away from the initial problem of authentication.

mark.

[Matt Deegan]

(butting in)

The idea is that App Layer would pull in the tags from any
authenticated UDID that a user adds. It's a bit like oAuth in Twitter.
I delegate the ability for the App Layer to talk to each of my
device's Tag Providers. It can then pull in these TimeStamps and
StationIDs and do *something* with them.

I think there is an issue if we start from the assumption that
broadcasters own the tags. As a user I might tag something for a
variety of reasons:
* Things I love
* Things I hate
* Music I like
* DJs I want to listen to
* DJs I want to block

I think we should think of the USER owning the tag and then delegating
to an App Layer (which i'm sure for many people will be their
favourite radio station's website) the ability to manage it.

Also, just because a user tags something doesn't mean they want the
radio station they've tagged to know that they've done it. There could
even be a data protection issue with that information being passed
across.

Matt.

[Paul Fairburn]

I've been worried about the data protection issues too. There's a competitive issue too, if one service/station has access to a listener's tags from another service - surely? It's the kind of thing that *might* put broadcaster off the idea.

Paul Fairburn

[Matt Deegan]

I think this is where EPG & VIS is quite different to TAG as with TAG
it doesn't neccessarily *need* the Broadcaster to be invovled.

In effect, an App Layer *may* provide context. The original
broadcaster may provide the best context, but a third party might do
that too.

Also, if a Broadcaster chooses not to be involved, the tagging will
all still work - allowing others to provide the context. You could
argue that the openness of this will encourage the broadcasters to get
involved and provide good context so they can collect users' tags data
(after they've been authorised).

Now, a broadcaster could shun all of this and do their own tagging (on
the web/iphones app etc) - but would miss out on a broader selection
of data
Or, a manufacturer could build their own tagging system - but they
would miss out on bring able to surface tags from other devices (and
enahnce the value to users who might be using multiple devices to
tag).

I think the key is giving Users the ability to authorise Tag Providers
to speak to App Layers (with RadioTAG HQ connecting the two).

The Twitter eco-system (with oAuth) is a really interesting parallel.
It's success has been in its openness to let third parties interact
with the core data. This has served to make 'tweeting' univeral,
whilst still maintaing Twitter.com as still the biggest client (and I
would expect in our example each radio station would be the biggest
App Layer client too).

Matt.




On Aug 2, 6:20 pm, Paul Fairburn <paul.fairb...@smoothradio.co.uk>
wrote:

[Mark Glanville]

Ok, that's a good point about context being provided by a third party.
I'm not sure who that would be but it's perfectly feasible and has
revenue-generation potential as well. However, what we're describing
here seems quite different from what's described in the current
(albeit draft) version of the RadioTAG tech spec. It talks about
RadioTAG as a /service/ (similar to EPG or VIS) that provides the user
with context information for 'tags' (essentially timestamps, possibly
with a comment attached) on radio broadcasts they've listened to,
either live or time-shifted.

What we're talking about here is a system that doesn't require the
broadcaster to ever see the tags about their broadcasts; allowing
devices (possibly via a manufacturer's portal) to send tags to ANY
application layer. This doesn't require the DNS part of RadioDNS at
all. The tags would still use the broadcast parameters to identify the
broadcast, but there's no need for the DNS lookup to check if the
tagging 'service' is available because the application layer will
provide that service regardless of whose broadcast the tags pertain
to.

I think we need to have a separate discussion about what we expect
RadioTAG to be used for. At the moment I'm confused.

mark.

[Sebasti...@swr.de]

jup ... so am I

:-(

Maybe we can indeed make the loop and collect the requirements first.

[A. F.]

I think we've got the basics right in the current RadioTAG draft. Tags should go to a service named via RadioDNS. RadioTAG does not work, if the broadcaster has no TAG service entry in his DNS record.

We're building a RadioDNS tagging application, not an interaction protocol for application development. The spec reads: «The device generates a tag with relevant parameters required to provide contextual information on the event at a later time.»

There are lots of applications in the "provide contextual information» bit, of course. Broadcaster can and will use the TAG for whatever they want. ("hit the tag button now, and you'll participate in our contest....etc etc")

But that doesn't mean RadioTAG should just do what it's supposed to: 1) prepare a tag on the device and 2) get it to a service defined by the broadcaster

What the broadcaster finally does with the tag, is completely outside the RadioTAG spec.

That said, I still think we should discuss an OAuth like model.

André

[Mark Glanville]

I'm not saying we can't have a discussion, but it looks like it's been
discussed before and discounted:

Page 7 of the current spec (v0.6.1) states
"Note: Due to the nature of many existng radio devices, the necessary
steps involved with
distributed authentcaton protocols such as OAuth are not possible."

I'm not sure why existing radio devices are of concern. I agree they
probably won't be able to do OAuth, but are they likely to be able to
do the rest of RadioTAG anyway?

mark.

[Andy Buckingham]

Thanks for all your input so far, I'm hoping I can aid with "closing
the loop" as Sebastian suggested.

The original concept for tagging was to provide a way for a user to
tap a button to express interest (positive or negative, as Matt
suggested) in something that they have heard to be able to later use
the meta associated with the event tagged. Our aim is to achieve this
simple "tag and discover" model with the most simplified UX as
possible.

It was also suggested, as André points out, that a broadcaster may use
that tagged information to provide a timely service, for example "Tag
now to vote" or "Tag now to receive a free sample". This kind of
interaction would require the tagged data to ultimately reach the
service provider from the device, although there is no reason why a
party cannot sit in the middle.

However, in Matt and David's suggestion this cannot happen without
additional interaction on a radio station's website which breaks our
"out of the box" functionality requirement. Is there a way that the
party in the middle could forward that data to the broadcaster (maybe
anonymously?) to provide functionality such as the "tag to vote"?

I appreciate that something like offering a free sample of a product
via a tag would require a full registration process with the
broadcaster anyway, so that could be covered off more clearly via on
air mentions such as "Tag now then log on to capitalfm.com to receive
a free sample". This is the point where the device ID would be
inputted to pull down the tag data from the other tag holding point
and populate and process things such as a free offer?

The central database of UDI's raises some concerns for me. Firstly, I
believe RadioDNS would like to avoid maintaining such a database.
Secondly, I foresee manufacturers being unhappy to have the additional
overhead of registering devices up and agreeing formats for these
numbers etc. I think they'd much rather use an identifier they already
hold, for example.

One possible solution to this would be to use something like MAC
addresses? I'd need to do a little more research on these, but I do
believe a part of this includes an identifier to spot the manufacturer
or vendor. Could these vendor ID's then somehow be referenced to the
appropriate tag holding service?

Finally, could I introduce the use case of a third party wanting to
write a streaming audio client app for a mobile device. They are not
affiliated with a broadcaster so effectively they are their own
"manufacturer". Where would they initially send tags to? They could
implement their own tagging receiver "middleman", but that
significantly raises the barrier for entry. How could we ease that
path of implementation?

[Andy Buckingham]

The note on OAuth were written from the viewpoint of implementing the
OAuth challenge on the device to the broadcaster.

If you think of a simple 2 line display radio device, there is no way
to render a HTML page with a user/password challenge.

However, in the recent suggestions this has been spun on its head by
being done at the opposite end (service provider linking to device)
which means they are likely to be in a web browser - thus resolving
the previous issue.

Certainly worth exploring further.

[James Cridland]

On Aug 3, 1:09 pm, Andy Buckingham <andy.bucking...@radiodns.org>
wrote:

> Secondly, I foresee manufacturers being unhappy to have the additional
> overhead of registering devices up and agreeing formats for these
> numbers etc. I think they'd much rather use an identifier they already
> hold, for example.

It might be worthwhile knowing that, in the case of a connected device
such as the PURE Sensia, this is likely already to be registered to a
user through the PURE web portal The Lounge (which I find myself the
editor of currently).

If a PURE Sensia user tags something, then Capital FM could
potentially get something saying "hey, user 274632 at thelounge.com
tagged at xxxxx time".

If Capital FM has a "connect your Capital VIP account to your PURE
radio" system (OAuth please)... Capital could then retrieve the tags
that the user made while listening to Capital; but The Lounge could
show all the tags that this user made.


For your other use-case, if a device isn't registered, then Capital FM
could potentially get something sating "hey, MAC address 27:45:22:x4
tagged at xxxxx time". Not sure how easily a user could register this
on Capital FM's website, though.


I guess the issue is that I don't quite know what a 'tag' would be
used for. Are we assuming it's one button or two? Are we assuming that
it won't be possible to give this button a software-controlled label
("VOTE", "BUY SONG", "MORE")? I can't see broadcasters reading out
instructions on how to tag if we're talking about a tiny, tiny amount
of people initially.

//j

[Sebastian]

Wow - a lot of traffic in this thread ... really hard to read and
think about it whilst including these thoughts into an appropriate
answer :-)
Thanks for clarifiying the basic concept Andy ... however my feeling
is still mixed.

Reading the Spec and the thread I conclude a lot of requirements:
- a Tag consists of protocol vs., auth. token, UDI, timestamp, bearer
- a Tag is created via user interaction
- a Tag can be stored locally ... being exchanged at a later point of
time
- a Tag belongs to one certain service provider
- users wish to syndicate their tags they have created on several
devices
- users wish to syndicate their tags they have created per provider
- users wish to move their created tags from device a to device b
(e.g. if they sell a)
- third parties might wish to provide solutions too

But the most important sentence (in the Spec) is that "the tag usage
is expected to be proprietary"

I'd guess that it will be absolutely necessary to define a few use-
cases or basic tag-applications ... e.g. as James suggested (VOTE, BUY
SONG, MORE) ... and to concentrate on them. This is the loop I was
trying to initiate. Broadcasters as well as solution providers need
assistance in "what (and why) they should implement". The clearer and
simpler a certain function is, the earlier it is implemented.

I don't want to thwart the progress ... but after following the
discussion for a while I have the feeling that the "can do everything"
spec is slightly too much for the first throw ...?

Best
Sebastian.

[Andy Buckingham]

RE: the purpose of the button (and potential to label it other things)

When I first threw the basics of the spec together my interpretation
of the concept of tagging was that the specific interaction didn't
matter. On a crowded bus with a headset button or driving a car with a
steering wheel stalk button labelled 'Tag', you just press the button
when you hear something interesting. It could be to
vote/buy/download/watch/anything. The main point is you say "this is
of interest".

The interaction would then occur elsewhere via desktop or mobile web
access, with a user interface of the service providers choice. This
could facilitate any/every function desired.

[Andy Buckingham]

On 3 August 2010 13:28, James Cridland <james.c...@gmail.com> wrote:
> On Aug 3, 1:09 pm, Andy Buckingham <andy.bucking...@radiodns.org>
> wrote:
>> Secondly, I foresee manufacturers being unhappy to have the additional
>> overhead of registering devices up and agreeing formats for these
>> numbers etc. I think they'd much rather use an identifier they already
>> hold, for example.
>
> It might be worthwhile knowing that, in the case of a connected device
> such as the PURE Sensia, this is likely already to be registered to a
> user through the PURE web portal The Lounge (which I find myself the
> editor of currently).

I didn't explain this as clearly as I should...

I was referring to the centralised lookup system that would match the
UDID to the tag holding location, not a user registration. How would
Capital FM know that device ID XZYD123456 is actually a Pure device
with tag data at thelounge.com ?

Whilst the example given of registering your Pure Lounge device works,
this obviously doesn't scale to many different manufacturers.

How can we reduce the requirement on a centralised RadioTAG body to
link device ID's to tag holding servers? Could we follow the model of
OpenID with a domain/URL? Does this add even more complication to the
registration process on a radio station/apps website?

This is why I was thinking of the MAC address model with a
manufacturer identifier inside, and a simple (DNS based?) lookup to
match manufacturer ID to a server FQDN?

[Andy Buckingham]

Hello again.

We've done some more head scratching here and revisited both suggested
methods currently on the table to see if we can take learnings from
both and create a hybrid model that sits somewhere between the two.

We started by identifying three "ideal scenario" stages based on the
previously described requirements for tagging:

1. Simple Device-Only Tagging Mode
Tagging works out of the box, but tags are only visible on the device
that created them.

2. User-associated Tagging Mode
Tags from all user-associated devices are visible on both devices and
the service provider's website, but only for this single service
provider.

3. Fully Syndicated Tagging Mode
All tags from all devices against all (authorised) service provider's
are visible on both devices and broadcasters websites.

This led us to formulating the following possible processes:

Simple Device-Only Tagging Mode

1. User un-boxes a shiny new radio, plugs it in, tunes to Service A
and hits the tag button.
2. The radio sends a 'tag' request to the RadioDNS-resolved server for
the currently consumed service. This tag contains service identifiers,
a unique device identifier (UDI) and the tag date/timestamps.
3. The service provider stores the received tag against the device's
UDI. They return an API-key for this device only that must be used in
all future exchanges. The device stores this keyed against the tagging
servers domain.
4. To populate a 'View Tags' menu, the device can make a separate
request to each known tagging server using the UDI and API key to
obtain a MediaRSS document.

User-associated Tagging Mode

1. User visits the website of one of the service providers they have
been tagging and notices the 'sign up to view tags' option. They
register for a new user account or login under an existing user
account and then get to the 'link up your devices' page. This page
requests the user be tuned to Service A, then go to the 'Pair Device'
option on their unit and make a request.
2. The service provider responds to this incoming request for a PIN
code that is valid for an arbitrary amount of time, which is then
displayed on the devices screen.
3. The user inputs the PIN code on the website. This completes an
authenticated link between device and user account.
4. Other devices are then completed in the same way. When any one of
those devices later requests the 'view tags' document it will now
contain all tags for all devices that user owns.

Fully Syndicated Tagging Mode

1. When the device sends it's first tag request to a service provider,
the response includes a second syndication API key for this tagging
server and asks the device to make another request containing details
of all known tagging servers this device has previously interacted
with.
2. The device prompts the user "Share all tags with Service A?". If
the user responds 'Yes', the device makes a second request which
includes the FQDN for all tagging servers it has previously delivered
tags to, along with the UDI and a read-only syndication API key.
3. The service provider can now iterate through the other tagging
servers in this response and, using it's read-only syndication API key
act as "pseudo device" to get the same media RSS feed as a device to
show all the users tags against other service providers alongside the
ones from this service provider.

The benefits over the previously described methods:

* it avoids the need for a centralised database, something that the
RadioDNS board are keen to avoid due to cost, complexity and
management.
* it doesn't require an intermediary tagging "holding house" in the
middle, but allows manufacturers to still provide that functionality
should they wish (the device would forward tags to the manufacturer,
the manufacturer would behave like the device.)
* it allows syndication across providers with user control over what
gets shared where

We have identified one or two minor bumps with the above methodology
which should be relatively simple to resolve, but I'd like to get the
groups opinions on the big picture idea and see if others agree this
gives us a possible middle option.

I look forward to your feedback.

Andy Buckingham,
Global Radio

[A. F.]

We started by identifying three "ideal scenario" stages based on the
previously described requirements for tagging:

Some litmus test would be: If we can explain this to a user in the device manual, it should work. But it certainly doesn't sound easy. Tell the user that there are 3 modes, that he has to register, enter PINS, allow sharing etc. For every step, we probably loose a couple of RadioTAG users.

What are the minor bumps you mentioned, Andy?

[In principle I'd prefer a username model, last.fm style. But I'm not going to promote this here, as it is not usable on very simple radio devices] 

André

[Andy Buckingham]

Apologies, the intended audience of my e-mail and explanation were
very much at a technical level.

Here's a very rough attempt at explaining to a user:

* Hear something of interest in your radio? Hit the tag button.
Navigate to 'View Tags' to view these tags.
* Want to find out more? Visit the radio stations website to view tags
and more details. The address is shown in the 'View Tags' section of
your device.

On the radio station websites, the prompts would be:

1. Login / Signup
2. Link your device(s) to your account - press the Auth button on your
device NOW, then enter the PIN code: [PIN]

At this point, if the service provider supports syndication the device
would provide a prompt along the lines of:
"Share tags from other stations with ServiceX?" [Share] / [No Thanks]

Back on the website:

3. Thanks! Your device is now linked to your account and we've also
linked up with ServiceY and ServiceZ. You can view all your tags on
any of our websites.

Could someone convince me that this is more complicated than, say,
linking a Twitter account to Facebook?

[A. F.]

Yes, very nice.

André 

[Andy Buckingham]

Since my last communication I've not heard from any participants as to
why the most recently proposed tagging methodology would be better or
worse than those suggested before it. Therefore as it provided some
improvement over previously discussed methods I would like to progress
discussion further with a view to getting a draft of the proposal out
shortly. As it stands, the revised proposal is as follows:

Simple Device-Only Tagging Mode

Tagging works out of the box, but tags are only visible on the device
that created them.

1. On a factory default device a user tunes to Service A and hits the
tag button.

2. The radio sends a 'tag' request to the RadioDNS-resolved server for
the currently consumed service. This tag contains service identifiers,
a unique device identifier (UDI) and the tag date/timestamps.

3. The service provider stores the received tag against the device's
UDI. They return an API-key for this device only that must be used in
all future exchanges. The device stores this keyed against the tagging
servers domain.

4. To populate a 'View Tags' menu, the device can make a separate
request to each known tagging server using the UDI and API key to
obtain a MediaRSS document.

User-associated Tagging Mode

Tags from all user-associated devices are visible on both devices and

the service provider's website, but only for this single service
provider.

5. User visits the website of one of the service providers they have

been tagging and notices the 'sign up to view tags' option. They
register for a new user account or login under an existing user
account and then get to the 'link up your devices' page. This page
requests the user be tuned to Service A, then go to the 'Pair Device'
option on their unit and make a request.

6. The service provider responds to this incoming request for a PIN

code that is valid for an arbitrary amount of time, which is then
displayed on the devices screen.

7. The user inputs the PIN code on the website. This completes an

authenticated link between device and user account.

8. Other devices are then completed in the same way. When any one of

those devices later requests the 'view tags' document it will now
contain all tags for all devices that user owns.

Fully Syndicated Tagging Mode

All tags from all devices against all (authorised) service provider's

are visible on both devices and broadcasters websites.

9. When the device sends it's first tag request to a service provider,

the response includes a second syndication API key for this tagging
server and asks the device to make another request containing details
of all known tagging servers this device has previously interacted
with.

10. The device prompts the user "Share all tags with Service A?". If

the user responds 'Yes', the device makes a second request which
includes the FQDN for all tagging servers it has previously delivered
tags to, along with the UDI and a read-only syndication API key.

11. The service provider can now iterate through the other tagging

servers in this response and, using it's read-only syndication API key
act as "pseudo device" to get the same media RSS feed as a device to
show all the users tags against other service providers alongside the
ones from this service provider.

As discussed, this has some known issues would I would appreciate
peoples thoughts on how we could tackle:

* Malicious third party tagging

A malicious third party could send spoof tags to a service provider,
incrementing through a range of UDI values in a known manufacturers
pattern. If they did this before an actual device had been first used
by a user, it would mean the device would not hold an API key but the
service provider would have issued one to the malicious third party.
The mismatch in API keys would fail authentication when the real
device attempted to first tag.

This could be resolved by providing a reset auth method. If a device
is still in Mode A (above), this would probably be an on-device option
on the device. That forces the service provider to issue a new auth
key. However, this would simply be a case of the malicious third party
doing the same thing again backwards and forwards ad infinitum?

Fundamentally, we need to question what the malicious third party
gains from carrying out this kind of attack and against this how
technically difficult it is to achieve. The lower the gain and higher
the technical complexity, the better. Theoretically, they could use it
to tag a specific event on a radio station which they want to include
on as many peoples 'Recent Tags' list as possible. The realistic gain
from this is questionable.

It could be made a web-based option, whereby the device pops up a
supplied message "Problem occurred, please visit capitalfm.com/reset
and enter code ABCD" where the user needs to enter the code on the
device and complete a captcha, thus making scripted large scale
attacks significantly more complicated.

* Device known services table synchronisation

A user tags stations X and Y on a new device, both operated by
different service providers. The user tags X first, then Y. Both
providers support tag syndication and therefore on first tagging
station Y and agreeing to share details, X and Y are notified of each
others existence and share tags from that point forward. At a later
time the user resets their device, clearing the table containing the
known services. They then begin to tag station Z. The service provider
for Z also supports syndication, but the device is unable to notify
the provider of the existence and previous history with services X and
Y.

The simplest way I can see of resolving this issue is to make a
necessary factor that until the user tags either X or Y again, Z will
not be linked up. If we agree with this step, it could be required the
device always reports known services once the user gives permission
and a diff comparison can spot changes. This way when, say, X was
tagged again, Z's existence would be reported back and X could notify
Z of Y's existence as well. To this extent the whole table could be
synced back to the device, allowing the state of the devices known
services table to be cloud-syncronised.

I look forward to hearing peoples thoughts.

Andy Buckingham,
Global Radio.

[James Cridland]

Keen to avoid re-registration if at all possible.

If a device is already associated with a user through a manufacturer,
it's clearly desireable to remove any re-registration. In this case,
should the device send something that identifies the manufacturer, and
allows the broadcaster to discover more about the manufacturer?

I'm thinking that a Matsui device might send 'tag.matsui.com' as part
of the tag; a broadcaster might query that FQDN to discover that
Matsui supports OAuth (and the OAuth URIs). If the user visited
www.radiosunshine.com/tag/a4e6 (in their tag list?) they might,
therefore, be offered the chance to "connect your RadioSunshine
account with your Matsui radio" - which would submit the UDI as part
of an OAuth string to the Matsui website.

This would potentially enable Matsui to hold a complete list of all
tags made by their radio's owner; and RadioSunshine to hold a list of
all tags made by this Matsui user on the RadioSunshine website? This
way, RadioSunshine only holds tags made on RadioSunshine.

Devices are already associated with users on Reciva and PURE devices,
as far as I understand it

//j (speaking personally)

[Andy Buckingham]

I agree that trying to avoid re-registration is a worthwhile and noble
effort.

In your proposal to OAuth between service provider and manufacturer,
how would this work if the manufacturer didn't want to implement a
server in the middle, or if the "device" was actually a piece of
software or a mobile application with no "manufacturer" as such?

I feel we'd still need something like the previously described as well
as the OAuth system for manufacturers and service provider. Surely
having 2 different methodologies fragments the implementation.
Ultimately I'm not sure what we gain from:

Option 1. Users like fabfm.com user account with manufacturer login.
(which doesn't work in some cases)
vs.
Option 2. User links fabfm.com user account to device itself.

Have I misunderstood the suggestion?

Of course one thing that is not very clear in the initial explanation
of the previously described methodology is the perfectly acceptable
possibility of a manufacturer sitting "in the middle" of tag
interactions. For example:

1. User already has their SensualTouch device linked to their Lobby
internet radio service account.
2. User hits the 'Tag' button. Tag is sent to The Lobby. The Lobby,
server side, acts as a device and sends the tag to the service
provider, receiving the authentication credentials etc. to provide the
tag information themselves.
3. Straight away tags are now viewable on the Lobby and also the
device. The user can then also attach their SensualTouch radio to
their FABFM user account in the previously suggested manner.
4. The user can then login to EITHER The Lobby OR the broadcaster (and
potentially those they've agreed to share with) OR see the tags on the
device.

On Aug 19, 1:43 pm, James Cridland <james.cridl...@gmail.com> wrote:
> Keen to avoid re-registration if at all possible.
>
> If a device is already associated with a user through a manufacturer,
> it's clearly desireable to remove any re-registration. In this case,
> should the device send something that identifies the manufacturer, and
> allows the broadcaster to discover more about the manufacturer?
>
> I'm thinking that a Matsui device might send 'tag.matsui.com' as part
> of the tag; a broadcaster might query that FQDN to discover that

> Matsui supports OAuth (and the OAuth URIs). If the user visitedwww.radiosunshine.com/tag/a4e6(in their tag list?) they might,

[James Cridland]

On Aug 20, 9:11 pm, Andy Buckingham <andy.bucking...@radiodns.org>
wrote:

> In your proposal to OAuth between service provider and manufacturer,
> how would this work if the manufacturer didn't want to implement a
> server in the middle, or if the "device" was actually a piece of
> software or a mobile application with no "manufacturer" as such?

My suggestion is simply that a device with the 'server in the middle'
signals this to the broadcaster.

So, a tag from a mobile application with no 'manufacturer' might just
contain:
"I'm [UID] and I've just tagged [station] at [time/date]"

...whereas a tag from an internet radio registered at FQDN might
contain:
"I'm [UID] at [FQDN] and I've just tagged [station] at [time/date]"

This would then allow an enterprising broadcaster to link the
listener's internet radio account with their own user registration
service (in practice, sucking names/email addresses/passwords from the
listener's internet radio account into their VIP systems, with
permission from the listener).

In your own parlance - this should significantly speed up user
registration for FabFM; and ensure that all tags for a listener are
held in TheLobby. It doesn't, however, get in the way of the (less
nice) user experience where they have to register individually for
each service.

I ought to point out that this might not be acceptable to TheLobby's
business owners; but given that all of the major operators of these
internet radio accounts are RadioDNS Members, we should be able to get
quick feedback should we require it.

--
Where new platforms and radio collide: http://james.cridland.net/blog/

UK: +44 7941 251474 | US: +1 617 299 9572 | GTalk:
ja...@cridland.net
Twitter: @jamescridland | Web: http://james.cridland.net/
Not At All Bad Ltd | http://notatallbad.ltd.uk/legal_info/