[CALL] OAuth2 Compliance

[Andy Buckingham]

At the time of producing the RadioTAG Draft 5 specification the OAuth2 specification was yet to be finalised.

Now this process is complete it might be worthwhile reviewing the final document to see if it would be possible to fully align RadioTAG to an OAuth2 model.

Failing that, is there anything we can learn or more closely follow to ease understanding? For example changing the RadioTAG­-Auth-­X style HTTP headers to WWW-­Authenticate/Authorization headers.

This feels like a worthwhile piece of work, but I would appreciate other peoples thoughts. We may ultimately end up parking this as an objective depending on the outcome of a wider discussion on which auth model to use, but if we can capture thoughts here it can guide our desire to have OAuth2 compliance in whichever auth model we adopt in the future.

[Andy Buckingham]

I received a question privately regarding the impact of splitting auth from Tag and if it would then make it easy to just adopt OAuth2 as a standard.

I initially foresee the following issues with OAuth2, though I am first to admit I am no expert on the spec, so please do let me know if you spot something I've missed:

1. Code/token exchange auth would require the Device to have a secret known between Device and Service Provider out of band
   I can't see a way this works with manufacturers implementing hardware devices and developers implementing software clients independently, nor can I see a scalable way that implementers could speak with all Service Providers worldwide to exchange secrets.
   
   
2. Device auth via basic PIN exchange was removed in an earlier draft
   The only auth method that works without a secret and therefore could work on a device is user/password exchange. I'm still concerned about this method on simple profile devices. That said, looking at the likes of Facebook and Google they seem to have cherry picked this feature out of the last draft it featured, in combination with later draft features.