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

Aaron Parecki aaron at parecki.com
Tue Jun 13 19:20:11 UTC 2023


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230613/cd3302c1/attachment-0001.html>


More information about the Openid-specs-ab mailing list