The basic flow hasn't really changed. Ultimately there is a client - the TV emulator - that communicates to OpenAM and the end user, with the end user also performing out-of-band operations via a device which has better UI capabilities - aka a tablet or laptop.
The app boots and initiates a request to OpenAM to get a unique user and device code, prompting the user to hit a specific URL on their tablet.
The user authenticates with the OpenAM resource server as necessary, enters the code and performs a consent dance to approve the request from the TV to be paired and retrieve data from the user's profile - in this case, overloading the postaladdress attribute in DJ to store favourite channel data.
In the meantime, the TV client is performing a polling operation - checking with the OpenAM authorization service, to see if the end user has entered the correct user_code and approved the request. Once completed the TV retrieves a typical OAuth2 bearer payload, including the refresh_token and access_token values that can be used to retrieve the necessary attributes.
Future requests from the TV now no longer need to request password or authorization data. By leveraging a long live refresh_token access can be managed centrally.
For more information on OAuth2 Device Flow see here.