| OpenID Connect Display TV and Fone | May 2023 | |
| Koiwai | Standards Track | [Page] |
An extension to the OpenID Connect Authentication Framework
defining new values for the display
parameter that instructs the OpenID Provider to provide proper screen content for TVs and Modern Feature Phones.¶
Several years of deployment and implementation experience with OpenID Connect Core 1.0 [OpenID.Core] has uncovered a need, in some circumstances, for the client to explicitly signal to the OpenID Provider that the user's device type is other than the originally defined screen types.¶
This specification allows the client to indicate to the OpenID Provider improving the user experience by reducing the friction for the user using televisions and feature phones.¶
This specification defines a new value for the display parameter.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
In the .txt version of this specification,
values are quoted to indicate that they are to be taken literally.
When using these values in protocol messages,
the quotes MUST NOT be used as part of the value.
In the HTML version of this specification,
values to be taken literally are indicated by
the use of this fixed-width font.¶
This specification uses the terms "authorization endpoint", "authorization request", "authorization response", and "client" defined by The OAuth 2.0 Authorization Framework [RFC6749].¶
In requests to the OpenID Provider, a client MAY indicate that the desired authentication and consent user experience is to fit a specific device.¶
An OPTIONAL parameter specifies how the OpenID Provider displays the authentication and consent user interface pages to the End-User. The following values are defined in this specification:¶
tvfonewap and fone is that fone
indicates the browser and the operating system of the device is modern (such as a Chromium-based browser on an Android-based operating system), and the device is capable of
showing richer html contents. The word fone is a shorten form of "feature phone".¶
When the display parameter is used in an
authorization request to the authorization endpoint with the value of
tv, it indicates that the user's device is a television.
A television typically has a big screen (more than 30 inches) and limited way of input methods such as a remote controller,
therefore, the OpenID Provider SHOULD provide a user interface with ease of use such as QR-code login.¶
When the display parameter is used in an
authorization request to the authorization endpoint with the value of
fone, it indicates that the user's device is a feature phone with a modern operating system.
A feature phone typically has a small screen (about 3 inches) and limited way of input methods such as ten keys and cursor keys,
without touch screen capability.
therefore, the OpenID Provider SHOULD provide a login screen fit such small screens.¶
If the OpenID Provider receives a display value that it does not support (not declared in the
display_values_supported metadata field) the OP SHOULD ignore the value.¶
In Figure 1 is an example of an authorization request
using the code response type
where the client tells the OpenID Provider that it wants the Provider to show the content
suitable for TVs.
(extra line breaks and indentation are for display purposes only).¶
GET /as/authorization.oauth2?response_type=code
&client_id=s6BhdRkqt3
&state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb
&scope=openid%20profile
&display=tv HTTP/1.1
Host: authorization-server.example.com
This specification extends the OpenID Connect Discovery Metadata Section 3 [OpenID.Discovery] and defines the following:¶
Specific to this specification, a value of
tv or fone in the array indicates to the Relying party
that this OpenID Provider supports such display type(s). If an OpenID Provider supports this specification
and has display_values_supported element in the openid-configuration file,
it MUST specify all display values which it supports.¶
If integrity protecting the authorization request is required, please refer to RFC 9101 [RFC9101].¶
This specification was developed within OpenID connect Working Group of the OpenID Foundation. Additionally, the following individuals contributed ideas, feedback, and wording that helped shape this specification:¶
Copyright (c) 2023 The OpenID Foundation.¶
The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.¶
The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.¶
2023-5-8¶