[CALL] Authentication "ahead of time"

[Andy Buckingham]

The BBC have conducted a recent exploration of RadioTAG with a view to produce an accompanying technology "TV Tag":

  http://www.bbc.co.uk/rd/blog/2013/03/authentication­for­connected­tvs

One particular area of interest in this study was the ability to query for the ability to register and status of registration "ahead of time". This allows an implementation to prompt the user to setup a registration without having to first tag an event.

I feel this is something we should look at incorporating in to RadioTAG, but still allow the ability to only register or prompt the user to register after attempting a tag.

[Robin Cooksey]

Hi Andy,

 

In the context of RadioTAG, I can see some advantages to allowing registration ahead of time – e.g. to get access to existing tags on an account, for example with a new receiver, or after a factory reset.

 

Originally – I think we accepted that the only way of triggering registration was to first create a tag, but I think this was a trade-off in an effort to try to keep things as simple as possible.

 

One observation is that in order to change the protocol to allow registration to be completed without tagging, I think all that is required is to obtain a receiver token and a suitable grant token to make the request to /registration_key.

If the protocol was to be changed, to allow the receiver to achieve this without having to post to /tag, then this would enable registration ahead of tagging.

However, if these changes have been made, then I think the same approach can be used for registration following a tag submission.

 

When you say “but still allow the ability to only register or prompt the user to register after attempting a tag”, are you suggesting that the broadcaster should be able to limit a receivers ability to register ahead of time, or that a device could choose not to allow registration ahead of time?

 

Best regards,

Robin

 

 

--
You received this message because you are subscribed to the Google Groups "RadioTAG developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radiotag-develo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andy Buckingham (RadioDNS)]

> When you say “but still allow the ability to only register or prompt the
> user to register after attempting a tag”, are you suggesting that the
> broadcaster should be able to limit a receivers ability to register ahead of
> time, or that a device could choose not to allow registration ahead of time?

Good point. I was only thinking about this from a device point of view.

We hit the usual issue if we make it optional on both sides sides, so
my gut instinct is to say the broadcaster MUST support both and the
device MAY do it either way.

This allows the manufacturer/developer of the device to be in control
over the finite difference in user experience, which feels important
as some devices will lend themselves far better than others. For
example, a large colour touch screen could dismiss a subtle
notification versus a 2 line display which would have to interrupt the
display of all other information to prompt the user.

[Robin Cooksey]

Hi Andy,

Thank you for the clarification.

So, if the broadcaster must support either approach, and the receiver can effectively choose which approach to follow; then I think from a protocol perspective - it just needs to support the authentication ahead of time approach only.

The receiver can then either allow the user to register only, or can offer to register after submitting a tag - but either way, it can use the same mechanism in the protocol. I.e., from a protocol perspective, I think there can still only be one method - and there's no need for two separate approaches.
The only slight complication is that I think it would still be useful for a tag response to indicate whether the user can register (i.e. is not currently registered, and the service supports it).

In fact, how will a receiver find out whether a service supports registration at all, in the registering ahead of time case?

Best regards,
Robin

> -----Original Message-----
> From: radiotag-...@googlegroups.com [mailto:radiotag-
> devel...@googlegroups.com] On Behalf Of Andy Buckingham (RadioDNS)
> Sent: 29 June 2013 11:43
> To: RadioTAG Application Team
> Subject: Re: [CALL] Authentication "ahead of time"
>
> > When you say "but still allow the ability to only register or prompt
> > the user to register after attempting a tag", are you suggesting that
> > the broadcaster should be able to limit a receivers ability to
> > register ahead of time, or that a device could choose not to allow
> registration ahead of time?
>
> Good point. I was only thinking about this from a device point of view.
>
> We hit the usual issue if we make it optional on both sides sides, so my gut
> instinct is to say the broadcaster MUST support both and the device MAY do
> it either way.
>
> This allows the manufacturer/developer of the device to be in control over
> the finite difference in user experience, which feels important as some
> devices will lend themselves far better than others. For example, a large
> colour touch screen could dismiss a subtle notification versus a 2 line display
> which would have to interrupt the display of all other information to prompt
> the user.
>
>

> On 28 June 2013 17:10, Robin Cooksey <Robin.Cooksey@frontier-

> silicon.com> wrote:
> > Hi Andy,
> >
> >
> >
> > In the context of RadioTAG, I can see some advantages to allowing

> > registration ahead of time - e.g. to get access to existing tags on an

> > account, for example with a new receiver, or after a factory reset.
> >
> >
> >

> > Originally - I think we accepted that the only way of triggering

> > http://www.bbc.co.uk/rd/blog/2013/03/authenticationforconnectedtvs

[Andy Buckingham]

To borrow from some common OAuth2 implementations, I notice that Google offers a "token status" endpoint that you can hit to query the state of your current token:

https://developers.google.com/accounts/docs/OAuth2UserAgent#validatetoken

We could replicate this concept to produce an endpoint to ascertain what the device is capable of doing with this particular service provider. For example, the device could hit /token-info and that response could do a couple of things:

1. Confirm the validity of the supplied authentication header "OK" or "FAIL" response with appropriate HTTP status code
   
2. Provide appropriate grants to the the device to indicate the availability of registration.
   

As I see it that should then provide a way for a device to do "ahead of time" registration without having to submit a tag.

> > an email to radiotag-developers+unsub...@googlegroups.com.

> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "RadioTAG developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send

> > an email to radiotag-developers+unsub...@googlegroups.com.

> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "RadioTAG developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to radiotag-developers+unsub...@googlegroups.com.

[Robin Cooksey]

Hi Andy,

 

Yes – looks like something along these lines would work, but still preserve the feature where grants are needed to perform a registration.

 

Best regards,

Robin

 

https://developers.google.com/accounts/docs/OAuth2UserAgent#validatetoken

> > an email to radiotag-develo...@googlegroups.com.

> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "RadioTAG developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send

> > an email to radiotag-develo...@googlegroups.com.

> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "RadioTAG developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to radiotag-develo...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out.
>

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

To unsubscribe from this group and stop receiving emails from it, send an email to radiotag-develo...@googlegroups.com.

[Ben Husmann]

Great conversation. I agree with where you two are going with it. Flexibility on the device side is key so that either user experience could be supported. If authentication "ahead of time" is supported, then in the case where the first authentification is attempted at the time of tagging, the process could take place in sequence. 1. authenticate, 2. register tag

This methodology is also in line with separating tagging from authentification.

[Robin Cooksey]

Hi Ben,

 

Thank you for your feedback.

 

Just to be clear, I assume we still want to support the unidentified/receiver use-cases of tagging – where the user can submit a tag without authentication.  I.e. as described in the “Levels of identity” section in the draft 5 specification.

The device first posts a tag – and displays the tag response to the user, without any need for complex user interaction (involving a device with a web browser).

If supported by the service, the device can then offer to allow the user to register – and effectively upgrade their level of identity to user.

 

The reasoning behind this was to offer a straight-forward out-of-the-box experience – and avoid putting off the user immediately by getting them to register first, before successfully submitting a tag.

 

So, I think the sequence would still need to be 1. Submit tag (including obtaining a receiver token if necessary), 2. Authenticate (register).

 

Best regards,

Robin

 

From: radiotag-...@googlegroups.com [mailto:radiotag-...@googlegroups.com] On Behalf Of Ben Husmann
Sent: 02 July 2013 22:09
To: radiotag-...@googlegroups.com
Subject: Re: [CALL] Authentication "ahead of time"

 

Great conversation. I agree with where you two are going with it. Flexibility on the device side is key so that either user experience could be supported. If authentication "ahead of time" is supported, then in the case where the first authentification is attempted at the time of tagging, the process could take place in sequence. 1. authenticate, 2. register tag

This methodology is also in line with separating tagging from authentification.

--

[Andy Buckingham]

It feels like we need a new endpoint to facilitate "ahead of time", which simply allows you to negotiate auth state (get an identifier if you don't have one, see if you can progress to registration state).

So for "ahead of time"...

1. Check status (get identifier, prompt to register if available)

2. Tag

For "at time"

1. Attempt tag

2. Potentially fail, get identifier, tag, prompt to register

etc.

To unsubscribe from this group and stop receiving emails from it, send an email to radiotag-developers+unsub...@googlegroups.com.