wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Be even clearer about the authority part

Browse source
This commit is contained in:
Alexey Rusakov 2021-03-30 19:40:34 +02:00
parent 9dd0854aee
commit 037ebbf1ca
1 changed files with 43 additions and 42 deletions
Download patch file Download diff file Expand all files Collapse all files

85
proposals/2312-matrix-uri.md
View file

@ -195,21 +195,23 @@ hyperlinks to Matrix URIs.
#### Authority
The authority part will eventually be used to indicate access to a Matrix
resource (such as a room or a user) specifically through a given server,
addressing a case described in
[matrix-org/matrix-doc#2309](https://github.com/matrix-org/matrix-doc/issues/2309).
Basing on
[the definition in RFC 3986](https://tools.ietf.org/html/rfc3986#section-3.2),
this MSC restricts the authority part to never have a userinfo component,
partially to prevent confusion concerned with the `@` character that has its
own meaning in Matrix, but also because this component has historically been
a popular target of abuse.
```text
authority = host [ ":" port ]
```
Further definition of syntax or semantics for the authority part is left for
future MSCs. Clients MUST parse the authority part as per RFC 3986 (i.e.
the presence of an authority part MUST NOT break URI parsing) but SHOULD NOT
use data from the authority part other than for experiments or research.
Here's an example of a Matrix URI with an authority part
(the authority part is `example.org:682` here):
`matrix://example.org:682/roomid/Internal_Room_Id:example2.org`.
The authority part, as defined above, is reserved for future MSCs.
Clients SHOULD NOT use data from the authority part other than for
experimental or further research purposes.
The authority part may eventually be used to indicate access to a Matrix
resource (such as a room or a user) specifically through a given entity.
See "Ideas for further evolution".
#### Path
This MSC restricts
@ -330,12 +332,12 @@ means performing an action on a URI with no `action` in the query.
The routing query (`via=`) indicates servers that are likely involved in
the room (see also
[the feature of matrix.to](https://matrix.org/docs/spec/appendices#routing)).
It is proposed to use the routing query to be used not only for resolving
In the meantime, it is proposed that this routing query be used not only with
room ids in a public federation but also when a URI refers to a resource in
a non-public Matrix network (see the question about closed federations in
"Discussion points and tradeoffs"). Note that `authority` in the definition
above is only a part of the grammar as defined in the respective section;
it is not proposed here to generate or read the authority part of the URI.
above is only a part of the _query parameter_ grammar; it is not proposed here
to generate or interpret the _authority part_ of the URI.
Clients MAY introduce and recognise custom query items, according to
the following rules:
@ -352,7 +354,7 @@ the following rules:
action should be respected as much as possible. Client authors SHOULD strive
for consistent experience across their and 3rd party clients, anticipating
that the same user may happen to have both their client and a 3rd party one.
Client authors are strongly encouraged to standardise custom query elements
that gain adoption by submitting an MSC defining them in a way compatible
across the client ecosystem.
@ -497,33 +499,33 @@ extensions. Here are a few ideas:
* Bring tangible semantics to the authority part. The main purpose of
the authority part,
[as per RFC 3986](https://tools.ietf.org/html/rfc3986#section-3.2),
is to identify the authority governing the namespace for the rest
of the URI. This MSC restates the RFC definitions for
[`host`](https://tools.ietf.org/html/rfc3986#section-3.2.2) and
[`port`](https://tools.ietf.org/html/rfc3986#section-3.2.3) but
doesn't go further, calling for a separate MSC that would define semantics of
the `host:port` pair. RFC 3986 also includes provisions for user
information but this MSC explicitly excludes them from the authority grammar,
on the grounds that user information has historically been a vector of
widespread abuse. If providing a user identity via the authority part is
found to be of value (with alleviated security concerns) in some case,
a separate MSC should both re-add it to the grammar of the authority part
and define how to construct, parse, and use it.
is to identify the entity governing the namespace for the rest of the URI.
The current MSC rules out the userinfo component but leaves it to a separate
MSC to define semantics of the remaining`host[:port]` piece.
Importantly, future MSCs are advised against using the authority part for
_routing over federation_ (the case for `via=` query items), as it would be
against the spirit of RFC 3986. The authority part can be used in cases when
a given Matrix entity is only available from certain servers (the case of
closed federations or non-federating servers). A request to the server
resolved from the authority part means that the client should be, as the name
implies, _authorised_ by the authority server to access the requested
resource. That, in turn, implies that the resource is either available
to guests on the authority server, or the end user must be authenticated
(and their access rights checked) by (or on behalf of) _that server_ in order
to access the resource. While being a part of the original proposal,
closed federations or non-federating servers).
While being a part of the original proposal in an attempt to address
[the respective case](https://github.com/matrix-org/matrix-doc/issues/2309),
the definition of the authority semantics has been dropped as a result of
[the discussion](https://github.com/matrix-org/matrix-doc/pull/2312#discussion_r348960282)
(also referred to in the previous section).
[the subsequent discussion](https://github.com/matrix-org/matrix-doc/pull/2312#discussion_r348960282).
A further MSC may approach the same case (and/or others) and define the
meaning of the authority part (either on the client- or even on
the server-side - provided that using Matrix URIs on the server-side brings
some other value along the way). This might not necessarily be actual DNS
hostnames even - one (quite far-fetched for now) idea to entertain might be
introducing some decentralised system of "network names" in order to equalise
"public" and "non-public" federations.
Along the same lines, if providing any part of user credentials via
the authority part is found to be of considerable value in some case,
a separate MSC could both reinstate it in the grammar and define how
to construct, parse, and use it - provided that the same MSC addresses
the security concerns associated with such URIs.
* One could conceive a URI mapping of avatars in the form of
`matrix:u/uid:matrix.org/avatar/room:matrix.org`
@ -583,10 +585,9 @@ further discussion should happen in GitHub comments.
they know the URI is not going to be used outside this federation.
Clients can facilitate that by having an option to always add or omit
the authority part in generated URIs for a given user account.~~
Use `via=` in order to point to a homeserver in the closed federation.
The authority part may eventually be used for that but further discussion
is needed on how clients should support it without compromising privacy
(see [the discussion on the issue](https://github.com/matrix-org/matrix-doc/pull/2312#discussion_r348960282)).
As of now, use `via=` in order to point to a homeserver in the closed
federation. The authority part may eventually be used for that (or for some
other case - see the previous section).
### Alternatives
@ -737,8 +738,8 @@ is taken to not make essential parts of the URI omittable to avoid
even accidental misrepresentation of a local resource for a remote one
in Matrix and vice versa.
The MSC intentionally doesn't support conveying any kind of user
information in URIs.
As mentioned in the authority part section, the MSC intentionally doesn't
support conveying any kind of user information in URIs.
The MSC strives to not be prescriptive in treating URIs except the `action`
query parameter. Actions without user confirmation may lead to unintended