Skip to content

Avoid use of term "scope" except in OAuth2 context #20

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jesusjuansalgado merged 1 commit into from
Oct 9, 2026
Merged

Avoid use of term "scope" except in OAuth2 context #20

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 11 additions & 25 deletions AuthVO.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -205,10 +205,6 @@ \subsection{Terminology}

The following terms are used with specific meanings in this document:

\todo{MT: Are these OK? Do they align with established usage?
Are there better choices?\\
BM: I haven't heard use of 'permit' before, but it seems like a
good choice to me.}
\begin{description}
\item[protected]
A service or resource that can only be accessed by authenticated users,
Expand All @@ -221,7 +217,7 @@ \subsection{Terminology}
\item[credentials]
Secret information known to a user, such as a username and password,
that can be used to acquire a {\em permit}
\item[authentication domain]
\item[domain]
A set of HTTP endpoints sharing the same authentication arrangements;
the same {\em permit\/} is applicable to all members of the same domain
and should not be presented to endpoints outside that domain
Expand Down Expand Up @@ -355,10 +351,10 @@ \section{Authentication Schemes}\label{sec:authschemes}
\verb|standard_id| for the credential submission method.


\subsection{Scope}\label{sec:scope}
\subsection{Domain}\label{sec:domain}

A major consideration for these schemes is authentication scope,
that is some rule about the domain (set of endpoints) within which an
A major consideration for these schemes is authentication domain,
that is some rule about the set of endpoints within which an
acquired permit is valid.
The permit is confidential information and so must not be leaked to services
outside the domain.
Expand All @@ -368,11 +364,11 @@ \subsection{Scope}\label{sec:scope}
The client may also be managing multiple permits
for multiple different domains at once.
So the permit must be delivered with sufficient
implicit or explicit scoping
implicit or explicit domain
information for the client to tell for each subsequent request
whether that permit should be presented,
i.e.\ whether it falls within that permit's domain.
The nature and form of this scoping information is scheme-specific.
The nature and form of this domain information is scheme-specific.



Expand Down Expand Up @@ -401,7 +397,7 @@ \subsubsection{\mbox{\tt ivoa\_cookie}}\label{sec:ivoa-cookie}
see Section~\ref{sec:standard-id}
\end{itemize}
\item[Login response:] \header{Set-Cookie} header
\item[Scope:] As defined by \rfc{6265}
\item[Domain:] As defined by \rfc{6265}
\end{description}

Cookies are text strings received in the {\tt Set-Cookie}
Expand All @@ -426,7 +422,7 @@ \subsubsection{\mbox{\tt ivoa\_cookie}}\label{sec:ivoa-cookie}
by \rfc{6265} for subsequent requests to protected resources.
If multiple cookies were received, they should all be presented.

Cookies come with an associated scope, defined by the content
Cookies come with an associated domain, defined by the content
of the \header{Set-Cookie} header in conjunction with \rfc{6265},
so compliant cookie-handling
libraries are able to determine the domain for a given cookie.
Expand Down Expand Up @@ -463,7 +459,7 @@ \subsubsection{\mbox{\tt ivoa\_x509}}\label{sec:ivoa-x509}
\end{itemize}
\item[Login response (if used):] PEM-encoded X.509 certificate chain
including private key
\item[Scope:] Origin of challenge URL
\item[Domain:] Origin of challenge URL
\end{description}

The \verb|ivoa_x509| challenge exists in two forms:
Expand Down Expand Up @@ -497,23 +493,13 @@ \subsubsection{\mbox{\tt ivoa\_x509}}\label{sec:ivoa-x509}
so there are no security issues associated with attempting to use them
to access services outside of the intended authentication domain.
However using them for inapplicable services is inefficient and clumsy
so some scoping is desirable.
so some rule for domain determination is desirable.
The authentication domain of a certificate acquired using this scheme is
considered to be the {\em Origin\/} of the URL from which
the challenge was received.
Origin is defined by section 4.3.1 of \rfc{9110}
and is a normalised triple of URI scheme, hostname, and port.

\todo{
I've made up this tentative scoping rule for certificates
without wider consultation.
It's what the AUTH library currently does.
Could use Protection Space like Basic Auth instead of Origin,
which just aggregates a Realm with the Origin.
Realm is not currently one of the parameters of this scheme,
but it could be added if anybody thought it was worth while.
}

There is an example in Section~\ref{sec:x509-example}.


Expand Down Expand Up @@ -560,7 +546,7 @@ \subsection{Bearer Tokens}\label{sec:ivoa-bearer}
\end{itemize}
\item[Login response:] an OAuth~2.0 access token of type \verb|Bearer|,
presented in the \header{Authorization} header of subsequent requests.
\item[Scope:] the resource named in the PRM document; the token's audience is
\item[Domain:] the resource named in the PRM document; the token's audience is
bound to that resource (see Section~\ref{sec:ivoa-bearer-flow}).
\end{description}

Expand Down
Loading