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/