Well-known URI

Last updated

A well-known URI is a Uniform Resource Identifier for URL path prefixes that start with /.well-known/. They are implemented in webservers so that requests to the servers for well-known services or information are available at URLs consistent well-known locations across servers.

Contents

Description

Well-known URIs are Uniform Resource Identifiers defined by the IETF in RFC 8615. [1] They are URL path prefixes that start with /.well-known/. This implementation is in response to the common expectation for web-based protocols to require certain services or information be available at URLs consistent across servers, regardless of the way URL paths are organized on a particular host. The URIs are implemented in webservers so that requests to the servers for well-known services or information are available at URLs consistently in well-known locations across servers.

The IETF has defined a simple way for web servers to hold metadata that any user agent (e.g., web browser) can request. The metadata is useful for various tasks, including directing a web user to use a mobile app instead of the website or indicating the different ways that the site can be secured. The well-known locations are used by web servers to share metadata with user agents; sometimes these are files and sometimes these are requests for information from the web server software itself. The way to declare the different metadata requests that can be provided is standardized by the IETF so that other developers know how to find and use this information.

Use

The path well-known URI begins with the characters /.well-known/, and whose scheme is "HTTP", "HTTPS", or another scheme that has explicitly been specified to use well-known URIs. As an example, if an application hosts the service "example", the corresponding well-known URIs on https://www.example.com/ would start with https://www.example.com/.well-known/example . [1]

Information shared by a web site as a well-known service is expected to meet a specific standard. Specifications that need to define a resource for such site-wide metadata can register their use with Internet Assigned Numbers Authority (IANA) to avoid collisions and minimize impingement upon sites' URI space.

List of well-known URIs

The list below describes known standards for .well-known services that a web server can implement.

URI suffixDescriptionReferenceDate of IANA registration
acme-challenge Automated Certificate Management Environment (ACME) [2] 2019-03-01
ai-plugin.jsonManifest for a ChatGPT plugin. [3]
apple-app-site-associationAn Apple service that enables secure data exchange between iOS and a website. [4]
apple-developer-merchantid-domain-association Apple Pay [5]
ashrae BACnet - A Data Communication Protocol for Building Automation and Control Networks [6] 2016-01-22
assetlinks.jsonAssetLinks protocol used to identify one or more digital assets (such as web sites or mobile apps) that are related to the hosting web site in some fashion. [7] 2015-09-28
atproto-didHandle-to-DID resolution for AT Protocol [8]
autoconfig/mail Mozilla Thunderbird mail autoconfiguration service [9]
browserid Mozilla Persona
caldavLocating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV) [10]
carddavLocating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV) [10]
change-passwordHelps password managers find the URL for the change password section. [11]
coap CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets [12] 2017-12-22
com.apple.remotemanagementApple account-based user enrollment for Mobile device management [13] [14]
coreConstrained RESTful Environments (CoRE) Link Format [15]
csvmCSV metadata, Model for Tabular Data and Metadata on the Web [16] 2015-09-28
datLinks domain to Dat identifier, used by Beaker web browser. [17] [18]
did.json did:web Decentralized Identifiers (DIDs) for the Web
discordDomain verification for Discord account connection [19]
dntSite-wide tracking status resource [20] 2015-08-19
dnt-policy.txtA privacy-friendly Do Not Track (DNT) Policy [21] 2015-08-19
est Enrollment over Secure Transport (EST) [22] 2013-08-16
genidThe Resource Description Framework (RDF) Skolem IRIs [23] 2012-11-15
gpcGlobal Privacy Control (GPC) [24]
hobaHTTP Origin-Bound Authentication (HOBA) [25] 2015-01-20
host-metaWeb Host Metadata [26]
host-meta.jsonWeb Host Metadata [26]
http-opportunisticOpportunistic Security for HTTP/2 [27] 2017-03-20
keybase.txtUsed by the Keybase project to identify a proof that one or more people whose public keys may be retrieved using the Keybase service have administrative control over the origin server from which it is retrieved. [28] 2014-04-08
matrixProvides discovery for both client and server APIs to the Matrix federated protocol. [29]
mercureDiscovery of Mercure hubs. Mercure is a protocol enabling the pushing of data updates to web browsers and other HTTP clients in a fast, reliable and battery-efficient way. [30]
mta-sts.txtSMTP MTA Strict Transport Security Policy [31] 2018-06-21
niNaming Things with Hashes [32]
nodeinfoMetadata for federated social networking servers [33]
nostr.jsonDiscovery of Nostr public keys and related relays, according to NIP-05 [34] 2024-03-18
oauth-authorization-server OAuth Authorization Server Metadata [35] 2018-03-27
openid-configuration OpenID Connect [36] 2013-08-27
openorgOrganisation Profile Document [37] 2015-05-29
openpgpkey OpenPGP Web Key Service [38]
pki-validationCA/Browser Forum’s Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates [39] 2017-02-06
posh PKIX over Secure HTTP (POSH) [40] 2015-09-20
privacy-sandbox-attestations.jsonThe Google Chrome Privacy Sandbox attestation file [41]
pubvendors.jsonThe IAB pubvendors.json tech spec, which provide a standard for publishers to publicly declare the vendors that they work with, and their respective data rights/configuration. [42] 2020-09-07
reload-configREsource LOcation And Discovery (RELOAD) Base Protocol [43]
repute-templateA Reputation Query Protocol [44] 2013-09-30
resourcesyncResourceSync Framework Specification [45] 2017-05-26
security.txt Standard to help organizations define the process for security researchers to disclose security vulnerabilities [46] 2018-08-20
statements.txtStandard for collective contract signing [47]
stun-keySession Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization [48] 2015-06-12
tdmrep.jsonDomain-wide TDM (Text and Data Mining) reservation [49]
timeTime over HTTPS specification [50] 2015-12-09
timezoneTime Zone Data Distribution Service [51] 2015-08-03
uma2-configuration User-Managed Access (UMA) 2.0 grant for OAuth 2.0 authorization [52] 2017-06-20
vercel/flagsOverridable Feature Flag's for Vercel's Toolbar [53]
voidDescribing Linked Datasets with the VoID Vocabulary [54] 2011-05-11
webfinger WebFinger [55] 2013-03-15, 2013-09-06
xrp-ledger.toml XRP ledger node & account information. [56]

Related Research Articles

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

HTTP is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

A Uniform Resource Identifier (URI), formerly Universal Resource Identifier, is a unique sequence of characters that identifies an abstract or physical resource, such as resources on a webpage, mail address, phone number, books, real-world objects such as people and places, concepts. URIs are used to identify anything described using the Resource Description Framework (RDF), for example, concepts that are part of an ontology defined using the Web Ontology Language (OWL), and people who are described using the Friend of a Friend vocabulary would each have an individual URI.

A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that uses the urn scheme. URNs are globally unique persistent identifiers assigned within defined namespaces so they will be available for a long period of time, even after the resource which they identify ceases to exist or becomes unavailable. URNs cannot be used to directly locate an item and need not be resolvable, as they are simply templates that another parser may use to find an item.

A Service record is a specification of data in the Domain Name System defining the location, i.e., the hostname and port number, of servers for specified services. It is defined in RFC 2782, and its type code is 33. Some Internet protocols such as the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) often require SRV support by network elements.

Web standards are the formal, non-proprietary standards and other technical specifications that define and describe aspects of the World Wide Web. In recent years, the term has been more frequently associated with the trend of endorsing a set of standardized best practices for building web sites, and a philosophy of web design and development that includes those methods.

In computer hypertext, a URI fragment is a string of characters that refers to a resource that is subordinate to another, primary resource. The primary resource is identified by a Uniform Resource Identifier (URI), and the fragment identifier points to the subordinate resource.

<span class="mw-page-title-main">HTTP referer</span> HTTP header field

In HTTP, "Referer" is an optional HTTP header field that identifies the address of the web page from which the resource has been requested. By checking the referrer, the server providing the new web page can see where the request originated.

<span class="mw-page-title-main">HTTP 403</span> HTTP status code indicating that access is forbidden to a resource

HTTP 403 is an HTTP status code meaning access to the requested resource is forbidden. The server understood the request, but will not fulfill it, if it was correct.

The Handle System is a proprietary registry assigning persistent identifiers, or handles, to information resources, and for resolving "those handles into the information necessary to locate, access, and otherwise make use of the resources". As with handles used elsewhere in computing, Handle System handles are opaque, and encode no information about the underlying resource, being bound only to metadata regarding the resource. Consequently, the handles are not rendered invalid by changes to the metadata.

<span class="mw-page-title-main">HTTP location</span> Instruction by web server containing the intended location of a web page.

The HTTP Location header field is returned in responses from an HTTP server under two circumstances:

  1. To ask a web browser to load a different web page. In this circumstance, the Location header should be sent with an HTTP status code of 3xx. It is passed as part of the response by a web server when the requested URI has:
  2. To provide information about the location of a newly created resource. In this circumstance, the Location header should be sent with an HTTP status code of 201 or 202.
<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing a simultaneous two-way communication channel over a single Transmission Control Protocol (TCP) connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

<span class="mw-page-title-main">HTTP/1.1 Upgrade header</span> HTTP header field introduced in HTTP/1.1

The Upgrade header field is an HTTP header field introduced in HTTP/1.1. In the exchange, the client begins by making a cleartext request, which is later upgraded to a newer HTTP protocol version or switched to a different protocol. A connection upgrade must be requested by the client; if the server wants to enforce an upgrade it may send a 426 Upgrade Required response. The client can then send a new request with the appropriate upgrade headers while keeping the connection open.

httpRange-14 is a long-running logical conundrum or design problem in the semantic web. The problem arises because when HTTP is extended from referring only to documents to talking about real-world things the domain of HTTP GET becomes undefined.

A uniform resource locator (URL), colloquially known as an address on the Web, is a reference to a resource that specifies its location on a computer network and a mechanism for retrieving it. A URL is a specific type of Uniform Resource Identifier (URI), although many people use the two terms interchangeably. URLs occur most commonly to reference web pages (HTTP/HTTPS) but are also used for file transfer (FTP), email (mailto), database access (JDBC), and many other applications.

The JSON Meta Application Protocol (JMAP) is a set of related open Internet Standard protocols for handling email. JMAP is implemented using JSON APIs over HTTP and has been developed as an alternative to IMAP/SMTP and proprietary email APIs such as Google's Gmail and Microsoft's MAPI . Additional protocols and data models being built on top of the core of JMAP for handling contacts and calendar synchronization are meant to be potential replacements for CardDAV and CalDAV, and other support is currently in the works.

<span class="mw-page-title-main">Thing Description</span>

The Thing Description (TD) (or W3C WoT Thing Description (TD)) is a royalty-free, open information model with a JSON based representation format for the Internet of Things (IoT). A TD provides a unified way to describe the capabilities of an IoT device or service with its offered data model and functions, protocol usage, and further metadata. Using Thing Descriptions help reduce the complexity of integrating IoT devices and their capabilities into IoT applications.

References

Footnotes

  1. 1 2 Nottingham, Mark (May 6, 2019). Well-Known Uniform Resource Identifiers (URIs). IETF. doi: 10.17487/RFC8615 . RFC 8615.
  2. Barnes, Richard; Hoffman-Andrews, Jacob; McCarney, Daniel; Kasten, James (March 6, 2019). Automatic Certificate Management Environment (ACME). IETF. doi: 10.17487/RFC8555 . RFC 8555.
  3. "Getting Started - OpenAI API". platform.openai.com. Archived from the original on 2023-03-25. Retrieved 2023-03-25.
  4. "App Search Programming Guide: Support Universal Links". developer.apple.com. Archived from the original on 2016-03-31. Retrieved 2016-08-13.
  5. "Apple Developer Documentation". developer.apple.com. Archived from the original on 2016-09-20. Retrieved 2016-08-13.
  6. "Proposed Addendum am to Standard 135-2012, BACnet - A Data Communication Protocol for Building Automation and Control Networks" (PDF). Archived from the original (PDF) on 2018-05-08. Retrieved 2018-02-07.
  7. "Getting Started | Google Digital Asset Links". Google Developers. Archived from the original on 2016-11-05. Retrieved 2016-08-13.
  8. "Handle | AT Protocol". atproto.com. Archived from the original on 2024-02-16. Retrieved 2024-02-16.
  9. "Thunderbird:Autoconfiguration - MozillaWiki". Archived from the original on 2021-07-30. Retrieved 2021-07-30.
  10. 1 2 Daboo, Cyrus (February 6, 2013). Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV). IETF. doi: 10.17487/RFC6764 . RFC 6764.
  11. "A Well-Known URL for Changing Passwords". w3c.github.io. Archived from the original on April 21, 2022. Retrieved February 6, 2022.
  12. Bormann, Carsten; Lemay, Simon; Tschofenig, Hannes; Hartke, Klaus; Silverajan, Bill; Raymor, Brian (February 6, 2018). CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets. IETF. doi: 10.17487/RFC8323 . RFC 8323.
  13. "How users enroll their personal devices". support.apple.com. Archived from the original on 2024-08-15. Retrieved 2022-04-23.
  14. "Discover Authentication Servers". developer.apple.com. Archived from the original on 2024-08-15. Retrieved 2022-04-23.
  15. Shelby, Zach (August 6, 2012). Constrained RESTful Environments (CoRE) Link Format. IETF. doi: 10.17487/RFC6690 . RFC 6690.
  16. "Model for Tabular Data and Metadata on the Web". www.w3.org. 17 December 2015. Archived from the original on 2024-08-15. Retrieved 2021-10-06.
  17. "Use a domain name with dat://". beakerbrowser.com. Archived from the original on 2020-01-14. Retrieved 2020-08-24.
  18. "DEP-0005: DNS - Dat Protocol". www.datprotocol.com.
  19. "advaith (@advaith@mastodon.social)". Mastodon. 2023-07-17. Archived from the original on 2024-08-15. Retrieved 2023-08-29.
  20. "Tracking Preference Expression (DNT)". www.w3.org. Archived from the original on 2024-08-15. Retrieved 2021-10-06.
  21. "A privacy-friendly Do Not Track (DNT) Policy". Electronic Frontier Foundation. April 24, 2014. Archived from the original on May 11, 2021. Retrieved February 7, 2018.
  22. Pritikin, Max; Yee, Peter E.; Harkins, Dan (October 6, 2013). Enrollment over Secure Transport. IETF. doi: 10.17487/RFC7030 . RFC 7030.
  23. "RDF 1.1 Concepts and Abstract Syntax". www.w3.org. Archived from the original on 2024-08-15. Retrieved 2021-10-06.
  24. "Global Privacy Control (GPC)". Global Privacy Control (GPC) - Proposal 22 March 2024. Archived from the original on 2024-06-13. Retrieved 2024-06-13.
  25. Farrell, Stephen; Hoffman, Paul E.; Thomas, Michael (March 6, 2015). "Other Parts of the HOBA Process". HTTP Origin-Bound Authentication (HOBA). IETF. sec. 6. doi: 10.17487/RFC7486 . RFC 7486.
  26. 1 2 Cook, Blaine; Hammer-Lahav, Eran (October 6, 2011). Hammer-Lahav, E (ed.). Web Host Metadata. IETF. doi: 10.17487/RFC6415 . RFC 6415.
  27. Nottingham, Mark; Thomson, Martin (May 6, 2017). "The "http-opportunistic" Well-Known URI". Opportunistic Security for HTTP/2. IETF. sec. 2.3. doi: 10.17487/RFC8164 . RFC 8164.
  28. "The "keybase.txt" Well-Known Resource Identifier". keybase.io. Archived from the original on 2024-08-15. Retrieved 2018-02-07.
  29. "Client-Server API". Archived from the original on 2024-08-15. Retrieved 2020-06-17.
  30. "Mercure.rocks: Mercure: The Specification". mercure.rocks. Archived from the original on 2020-09-24. Retrieved 2019-11-21.
  31. Margolis, Daniel; Risher, Mark; Ramakrishnan, Binu; Brotman, Alex; Jones, Janet (September 6, 2018). "MTA-STS Policies". SMTP MTA Strict Transport Security (MTA-STS). IETF. sec. 3.2. doi: 10.17487/RFC8461 . RFC 8461.
  32. Farrell, Stephen; Kutscher, Dirk; Dannewitz, Christian; Ohlman, Börje; Keränen, Ari; Hallam-Baker, Phillip (April 6, 2013). Naming Things with Hashes. IETF. doi: 10.17487/RFC6920 . RFC 6920.
  33. "NodeInfo". July 19, 2021. Archived from the original on May 18, 2019. Retrieved February 7, 2019 via GitHub.
  34. "NIP-05: Mapping Nostr keys to DNS-based internet identifiers". github.com.
  35. Jones, Michael B.; Sakimura, Nat; Bradley, John (June 28, 2018). OAuth 2.0 Authorization Server Metadata. IETF. doi: 10.17487/RFC8414 . RFC 8414.
  36. "Final: OpenID Connect Discovery 1.0 incorporating errata set 1". openid.net. Archived from the original on 2021-10-28. Retrieved 2021-10-06.
  37. "Organisation Profile Documents". opd.data.ac.uk.
  38. Koch, Werner. OpenPGP Web Key Directory. IETF. I-D draft-koch-openpgp-webkey-service-07.
  39. "Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates" (PDF). Archived (PDF) from the original on 2018-09-10. Retrieved 2018-02-07.
  40. Miller, Matthew A.; Saint-Andre, Peter (November 6, 2015). PKIX over Secure HTTP (POSH). IETF. doi: 10.17487/RFC7711 . RFC 7711.
  41. "Enroll for the Privacy Sandbox". Google for Developers. Retrieved 2024-10-17.
  42. "web".[ dead link ]
  43. Jennings, Cullen; Lowekamp, Bruce; Rescorla, Eric; Baset, Salman; Schulzrinne, Henning (January 6, 2014). Lowekamp, B (ed.). REsource LOcation And Discovery (RELOAD) Base Protocol. IETF. doi: 10.17487/RFC6940 . RFC 6940.
  44. Borenstein, Nathaniel S.; Kucherawy, Murray (November 6, 2013). A Reputation Query Protocol. IETF. doi: 10.17487/RFC7072 . RFC 7072.
  45. "ANSI/NISO Z39.99-2017".
  46. "security.txt". security.txt.
  47. "The "statements.txt" Well-Known Resource Identifier". stated.ai.
  48. Reddy.K, Tirumaleswar; Patil, Prashanth; R, Ram; Uberti, Justin (August 6, 2015). Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization. IETF. doi: 10.17487/RFC7635 . RFC 7635.
  49. "TDM Reservation Protocol (TDMRep) ; Final Community Group Report". Text and Data Mining Reservation Protocol Community Group. 2022. Retrieved 2023-06-01.
  50. "20151129 Time over HTTPS specification — PHKs Bikeshed". phk.freebsd.dk. Archived from the original on 2019-05-31. Retrieved 2018-02-07.
  51. Douglass, Michael; Daboo, Cyrus (March 6, 2016). Time Zone Data Distribution Service. IETF. doi: 10.17487/RFC7808 . RFC 7808.
  52. Maler, E.; Machulak, M.; Richer, J. (January 7, 2018). "User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization". docs.kantarainitiative.org.
  53. "Toolbar Flags Reference". vercel.com. Archived from the original on 2024-09-09. Retrieved 2024-09-09.
  54. "Describing Linked Datasets with the VoID Vocabulary". www.w3.org. Archived from the original on 2021-10-22. Retrieved 2021-10-06.
  55. Jones, Paul; Salgueiro, Gonzalo; Jones, Michael; Smarr, Joseph (September 6, 2013). WebFinger. IETF. doi: 10.17487/RFC7033 . RFC 7033.
  56. "xrp-ledger.toml File | XRPL.org". xrpl.org.