[Rets-dev] Clarifying login/entitlements/authorization/session conformance

[Peter Williams]

Am I consistent with the intended model, in my reading of what follows
on the topic of login/entitlements/authorization/session?

I'm willing to take (compliance-only) interpretations into
consideration, for 14 days.

All quotes from http://rets.org/files/retsproto1.7d6.pdf



==================================================



"4.1.1 User Authentication

While this specification does not require the use of security - it is
permissible, for
example, to operate a publicly-accessible RETS server - most operators
of RETS servers
will wish to authenticate users. A server that requires that users be
authenticated MAY
implement RFC 2617, HTTP Authentication. The use of at least digest
authentication is
strongly recommended."





To this developer, it clear and conforming that one may authenticate
users, one MAY use digest authentication, and one MAY use techniques
stronger than digest authentication as a replacement for the RECOMMENDED
digest authentication. For example, one MAY use a combination of https
(suggested by section 4.13) together with client certificates and
careful SSL session resumption procedures, perhaps. In that case, the
recommended services of digest authentication would be provided by an
"appropriate", alternative means. Other appropriate means (arguably)
exist, but like client certificates and https, those means lie outside
the current compliance rules of RETS 1.7.

It is AMBIGUOUS whether one MUST use null-authentication (when handling
WWW-Authorization headers), if one is not making operational use of
digest auth.



==================================================


"4.7.5 Capability URL List

capability-url-list::= see Section 4.10 for format information

The server MUST return a capability list that includes at least Search,
Login and
GetMetadata. The server MAY in addition return any of the other types in
Section 4.10. If
the server supports any of the additional functions (and the client is
entitled to access the
function by virtue of the supplied login information), it MUST provide
URLs for those
functions. The server MAY supply URLs in addition to those in Section
4.10 based on the
user-agent. If it does, it MUST follow the format specified in Section
4.10."

"The capability-url-list is the set of functions or URLs to which the
login grants access. A
capability consists of a key and a URL. The list returned from the
server in the login reply
has the following format:"






To this developer, its clear and conforming that the act of login
"grants access" to several URL-addressed resources. The granting MAY
return other types beyond those enumerated in 4.10 (i.e. other X-URLs of
any legal URL syntax). Its also implied by the definition of login URL
in 4.10 that the login server may be distinct from the server that does
GETMETADATA, SEARCH, GETOBJECT, X-URL. Furthermore, GETMETADATA URL need
not be satisfied by the very same server that satisfies SEARCH URL (or
X-URL).

Open question: as the interaction with an X-URL resource is by
definition not standardized by RETS, I can see NO conformance rules in
_these_ sections governing how a RETS UA SHALL or MUST interact with the
server doing X-URL. However, the text does imply that a resource at
X-URL can infer (securely or otherwise) that the login process "granted
access", however.


==================================================


The only requirement I can see placed upon interaction with the  X-URL
resource is stated as follows:-

"A client MUST issue a login request prior to proceeding with any other
request. The Login
transaction verifies all login information provided by the user and
begins a RETS session.
Subsequent session control may be mediated by HTTP cookies or any other
method,
though clients are required to support at least session control via HTTP
cookies. Section 14
describes the session protocol in detail."



This indicates that the mandatory RETS session MAY be mediated by HTTP
cookies ("OR ANY OTHER METHOD"). It is clear that the login transaction
"begins a RETS session".


==================================================



"14
CHAPTER 

SESSION PROTOCOL

A RETS session follows a well-defined timing sequence in becoming
established and in
terminating. In particular, the authorization sequence MUST be followed
in order to begin
using other transactions within the protocol. The protocol contains four
phases:
connection establishment, authorization, session and termination."

This section indicates that a session comes into being ONLY upon
[positive] completion of the authorization phase.


==================================================


"14.1 Connection Establishment

A client initiates communication with a server by beginning a TCP
connection on any
mutually agreed TCP port, with the default being 6103 for unencrypted
connections, and
port 12109 for SSL-encrypted connections. When the TCP connection has
entered the
Established state, the session proceeds to the start of the
Authorization phase."


This text contradicts the text that precedes, indicating the session
exists prior to the start of the Authorization phase. Its possible (and
likely) that the term "session" refers to a load-balanced TCP or SSL
"flow-based-session", rather than a RETS-Session. A RETS-Session is not
the same as a TCP session, and has a different lifecycle.

Its also specified that port 12109 is only a default SSL (https) port. I
see nothing that indicates that one MUST use port 12019, or that one
MUST even offer 12019. Its just a default starting point for a UA to
try. A server may thus refuse an SSL connection on 12019, in a
conforming manner.



==================================================