Skip to content

Avoid use of term "scope" in non-OAuth2 contexts #19

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

Open
mbtaylor wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Avoid use of term "scope" in non-OAuth2 contexts #19

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
34 changes: 17 additions & 17 deletions AuthVO.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -214,7 +214,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 @@ -342,24 +342,24 @@ \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 \emph{authentication domain},
that is some rule about the set of endpoints for which an
acquired permit is valid.
The permit is confidential information and so must not be leaked to services
outside the domain.
The permit is confidential information and so must not be leaked to
(potentially hostile) services outside its domain of intended use.
But users may want to access multiple resources within the same domain
and should not be made to present their credentials
multiple times where not necessary.
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
information for the client to tell for each subsequent request
implicit or explicit information to allow the client
to determine for any given resource 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.
i.e.\ whether that endpoint falls within the permit's domain.
The nature and form of this domain information is scheme-specific.



Expand Down Expand Up @@ -388,7 +388,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 @@ -413,7 +413,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 All @@ -432,7 +432,7 @@ \subsubsection{\mbox{\tt ivoa\_x509}}\label{sec:ivoa-x509}
Certification Authority (CA) once its identification has
been verified by a Registration Authority.

A client in posession of a client certificate can then use it to
A client in possession of a client certificate can then use it to
sign TLS (HTTPS) connections, and the service can examine the signature
to authenticate the identity of the client.
Such authentication will succeed if the service trusts the signing CA.
Expand All @@ -450,7 +450,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 @@ -484,15 +484,15 @@ \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 domain restriction 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
I've made up this tentative domain restriction rule for certificates
without wider consultation.
It's what the AUTH library currently does.
Could use Protection Space like Basic Auth instead of Origin,
Expand Down Expand Up @@ -573,7 +573,7 @@ \subsection{Bearer Tokens}
associated standards, but at time of writing it's not clear which if
any of these are suitable for use by clients lacking prior knowledge
of the services for which they are intended,
and no standard scoping mechanisms seem to be defined.
and no standard domain restriction mechanisms seem to be defined.

This document does not therefore currently recommend any way in
which non-browser VO clients can use Bearer Tokens,
Expand Down