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/