[Openid-specs-ab] Call for adoption of Extra Display Types for OpenID Connect 1.0

[Kosuke Koiwai]

Thanks all for comments,

> Since the "feature phone" described has a full Chromium browser, "display=fone" would be better served by responsive web design of the authorization server page.
I don’t know of an easy way to detect the device’s HIDs before showing
the page and the user starts exploring it.
The User-Agent headers are getting more ambiguous.

> The OAuth Device Code flow was specifically created for these types of devices, and is a different protocol than the redirect-based flow.
Not all users have another device (pc/smartphone) to log in.

Kosuke

On Wed, Jun 14, 2023 at 4:20 AM Aaron Parecki via Openid-specs-ab
<openid-specs-ab at lists.openid.net> wrote:
>
> I do not support adoption of this document. Neither of the new values provide new functionality.
>
> Since the "feature phone" described has a full Chromium browser, "display=fone" would be better served by responsive web design of the authorization server page. (To add to the confusion, "feature phones" outside of Japan are typically characterized by the lack of a web browser. In fact, in OpenID Core, display=wap is described as for a "feature phone".)
>
> The "display=tv" value doesn't provide any context that isn't available elsewhere or would be better served by a different option entirely. Additionally, the actual intent is not to indicate the display, but to indicate the limited input capability of the device. There are also other types of devices that are not TVs that would benefit from the same type of interaction, for example small smart devices with touch screens but that lack a browser.
>
> The OAuth Device Code flow was specifically created for these types of devices, and is a different protocol than the redirect-based flow. In order to actually complete an OIDC flow with "display=tv" where there is no browser or limited input, the authorization server would have to create new custom solutions anyway. It would be far better to adopt the existing widely deployed OAuth Device Flow for these situations instead.
>
> Even if someone did want to vary the authorization server interface depending on the types of devices listed in this draft, that information is already available to the authorization server in the User-Agent header, and does not need to be conveyed by a new parameter.
>
> ---
> Aaron Parecki
>
>
> On Mon, Jun 12, 2023 at 5:50 PM Michael Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>>
>> We discussed Kosuke's proposal during today's working group call.  Those on the call were in favor of issuing a call for adoption.
>>
>> Please respond saying whether you are in favor of working group adoption or not within the next two weeks - by Monday, June 26th.  Comments on the draft are also welcomed.
>>
>>                         -- Mike (writing as a working group chair)
>>
>> -----Original Message-----
>> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Kosuke Koiwai via Openid-specs-ab
>> Sent: Monday, June 5, 2023 5:40 PM
>> To: Openid-specs-ab at lists.openid.net
>> Cc: Kosuke Koiwai <kkoiwai at gmail.com>
>> Subject: [Openid-specs-ab] Suggesting Core Extension: Extra Display Types for TVs and Modern Feature Phones
>>
>> Hi all,
>>
>> As discussed at the 23 May meeting, I would like to propose an extension to add display types for TVs and "modern" feature phones. Here in "modern"
>> feature phones, the difference from wap is that the browser and the operating system of the device is "modern" (such as Chrome and
>> Android) and the device is capable of showing richer html contents.
>>
>> https://bitbucket.org/openid/connect/issues/1927/core-extension-extra-display-types-for-tvs
>>
>> Please refer to the attached html or the online versions:
>> HTML: https://kosukekoiwai.bitbucket.io/openid-connect-extra-display-type-1_0.html
>> XML: https://bitbucket.org/kosukekoiwai/connect/src/master/openid-connect-extra-display-type-1_0.xml
>>
>> Thanks,
>>
>> Kosuke
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab