idnits 2.17.1
draft-pot-authentication-link-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 02, 2019) is 1667 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group E. Pot
3 Internet-Draft October 02, 2019
4 Intended status: Standards Track
5 Expires: April 4, 2020
7 Link relationship types for authentication
8 draft-pot-authentication-link-01
10 Abstract
12 This specification defines a set of relationships that may be used to
13 indicate where a user may authenticate, log out, register a new
14 account or find out who is currently authenticated.
16 Status of This Memo
18 This Internet-Draft is submitted in full conformance with the
19 provisions of BCP 78 and BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF). Note that other groups may also distribute
23 working documents as Internet-Drafts. The list of current Internet-
24 Drafts is at https://datatracker.ietf.org/drafts/current/.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 This Internet-Draft will expire on April 4, 2020.
33 Copyright Notice
35 Copyright (c) 2019 IETF Trust and the persons identified as the
36 document authors. All rights reserved.
38 This document is subject to BCP 78 and the IETF Trust's Legal
39 Provisions Relating to IETF Documents
40 (https://trustee.ietf.org/license-info) in effect on the date of
41 publication of this document. Please review these documents
42 carefully, as they describe your rights and restrictions with respect
43 to this document. Code Components extracted from this document must
44 include Simplified BSD License text as described in Section 4.e of
45 the Trust Legal Provisions and are provided without warranty as
46 described in the Simplified BSD License.
48 1. Introduction
50 [RFC8288] defines a framework and registry for Link Relationships
51 types. This specification defines a set of new relationship types to
52 aid clients in discovering endpoints for authentication and
53 registration: "authenticate", "authenticated-as", "logout" and
54 "register-user".
56 1.1. Usage examples
58 1.1.1. Browsers
60 Many websites already provide these features. If these links are
61 annotated with a standard relationship type, it might allow browser
62 extensions to automatically discover these and present them in new
63 ways. It could for example show a browser-level logout button.
65 Link relationships such as these could appear on any page where Sign
66 in, Register, Log in or Log out features exist.
68 1.1.2. Web services
70 Many webservices provide a resource to discover more information
71 about the authenticated entity. Creating standard link relationships
72 might allow a generic client to discover information about the
73 currently logged in user.
75 Similarly, an "authenticate" link could allow a generic client to
76 find an OAuth2 Authorization endpoint.
78 This link relationship could appear on any API endpoint where this
79 might be relevant, or it might just show up on central endpoint
80 discovery document.
82 2. authenticate
84 The "authenticate" can be used to link to a resource that hosts a
85 page where a user can authenticate itself for the current resource.
87 For example, this link might refer to a HTML login page.
89 Example:
91 Login
93 3. authenticated-as
95 The "authenticated-as" link refers to a resource that describes the
96 effective authenticated user for a HTTP response.
98 Following this link might allow a client to answer the question 'who
99 am I?'. This might link to a user profile page, or it might link to
100 an API that returns a JSON response with user information.
102 Example:
104 Link: ; rel="authenticated-as"
106 4. logout
108 The "logout" refers to a resource where an authenticated user might
109 end their session.
111 In a browser this might clear cookies, or in the case of OAuth2 it
112 could revoke any active authentication tokens.
114 5. register-user
116 The "register-user" Link Relation refers to a resource where a user
117 might sign up for a service for the context URI.
119 The linked resource might contain a HTML registration form, or
120 otherwise instructions that allow a client to find out how to sign up
121 for the service.
123 6. IANA considerations
125 This document defines "authenticate", "authenticated-as", "logout"
126 and "register-user" link relation types and adds them to the "Link
127 Relations" registry:
129 6.1. authenticate link relation
131 o Relation name: authenticate
133 o Description: Refers to a resource where a client may authenticate
134 for the the context URI.
136 o Reference: TBD
138 6.2. authenticated-as link relation
140 o Relation name: authenticated-as
142 o Description: Refers to a resource that describes the authenticated
143 entity for the HTTP response.
145 o Reference: TBD
147 6.3. logout link relation
149 o Relation name: logout
151 o Description: Refers to an endpoint where a client may invalidate
152 the current authentication session.
154 o Reference: TBD
156 6.4. register-user link relation
158 o Relation name: register-user
160 o Description: Refers to a resource where a client may create a new
161 user account for the context URI.
163 o Reference: TBD
165 7. Normative References
167 [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
168 DOI 10.17487/RFC8288, October 2017,
169 .
171 Appendix A. Changelog
173 A.1. Changes since -00
175 o More examples and clarifications
177 Author's Address
179 Evert Pot
181 Email: me@evertpot.com
182 URI: https://evertpot.com/