idnits 2.17.1
draft-pot-authentication-link-00.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 (May 02, 2019) is 1820 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 May 02, 2019
4 Intended status: Standards Track
5 Expires: November 3, 2019
7 Link relationship types for authentication
8 draft-pot-authentication-link-00
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 November 3, 2019.
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 2. authenticate
58 The "authenticate" can be used to link to a resource that hosts a
59 page where a user can authenticate itself for the current resource.
61 For example, this link might refer to a HTML login page.
63 Example:
65 Login
67 This specification doesn't define the authentication protocol. For
68 example, the link could refer to an OAuth2 authorization endpoint.
70 3. authenticated-as
72 The "authenticated-as" link refers to a resource that describes the
73 effective authenticated user for a HTTP response.
75 Following this link might allow a client to answer the question 'who
76 am I?'. This might link to a user profile page, or it might link to
77 an API that returns a JSON response with user information.
79 Example:
81 Link: ; rel="authenticated-as"
83 4. logout
85 The "logout" refers to a resource where an authenticated user might
86 end their session.
88 In a browser this might clear cookies, or in the case of OAuth2 it
89 could revoke any active authentication tokens.
91 5. register-user
93 The "register-user" Link Relation refers to a resource where a user
94 might sign up for a service for the context URI.
96 The linked resource might contain a HTML registration form, or
97 otherwise instructions that allow a client to find out how to sign up
98 for the service.
100 6. IANA considerations
102 This document defines "authenticate", "authenticated-as", "logout"
103 and "register-user" link relation types and adds them to the "Link
104 Relations" registry:
106 6.1. authenticate link relation
108 o Relation name: authenticate
110 o Description: Refers to a resource where a client may authenticate
111 for the the context URI.
113 o Reference: TBD
115 6.2. authenticated-as link relation
117 o Relation name: authenticated-as
119 o Description: Refers to a resource that describes the authenticated
120 entity for the HTTP response.
122 o Reference: TBD
124 6.3. logout link relation
126 o Relation name: logout
128 o Description: Refers to an endpoint where a client may invalidate
129 the current authentication session.
131 o Reference: TBD
133 6.4. register-user link relation
135 o Relation name: register-user
137 o Description: Refers to a resource where a client may create a new
138 user account for the context URI.
140 o Reference: TBD
142 7. Normative References
144 [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
145 DOI 10.17487/RFC8288, October 2017,
146 .
148 Appendix A. Changelog
150 A.1. Changes since -00
152 *
154 Author's Address
156 Evert Pot
158 Email: me@evertpot.com
159 URI: https://evertpot.com/