SSO Comments from Ray Plante

These comments were prepared in response to the SsoRFC.

Preface

Acknowledgements

I recommend that the following acknowledgement be included in the Acknowledgement section to acknowledge support for NVO-funded contributors, just prior to the last sentence:

US-NVO contributions were supported by the National Science Foundation's Information Technology Research Program under Cooperative Agreement AST0122449 with The Johns Hopkins University.

I would encourage other projects to provide similar statements as appropriate.

Definitions

In general, any document should spell any abbreviations the first time it is used. Some of our abbreviations may seem overly obvious or at least cumbersome to bother, but given that these documents will be read outside our community (if we do our job right), we should cross all our t's. For these obvious ones, I recommend a special preface section called "Definitions". Here's an adaptation of the boiler plate that I use:

The Virtual Observatory (VO) is general term for a collection of federated resources that can be used to conduct astronomical research, education, and outreach. The International Virtual Observatory Alliance (IVOA) is a global collaboration of separately funded projects to develop standards and infrastructure that enable VO applications. The International Virtual Observatory (IVO) application is an application that takes advantage of IVOA standards and infrastructure to provide some VO service.

Introduction

This document is likely to be a confusing read because (1) it talks about details that are explained in other documents, and (2) explanatory comments about these details--i.e. the "Comments" sections--appear after the introduction of these details. One way to alleviate this problem might be to add some cautionary statements to the Introduction. Try something like:

This document is essentially a profile against existing security standards; that is, it describes how an existing standard should be applied in an IVO application to support single sign-on capabilities in the IVO. In the following sections, we make specific references to details spelled out in those standard. For the purposes of validating against this standard, those referenced documents should be consulted for a full explanation of those details. Unfortunately, a reader that is unfamiliar with these external standards might find this specification confusing. To alleviate this problem, each major section is concluded by a Commentary subsection that provide some explanations of the detailed terms and concepts being referred to. The Commentary subsection may also provide recommended scenario for how this specification might actually be realized. Note that the statements in the Commentary subsections are non-normative and should not be considered part of precise specification; nevertheless, they are indicative of the intended spirit of this document.

I also recommend that we make sure that at least one explanatory statement be provided for each detail referenced from an external spec--particularly jargon.

2.2. Commentary

There is a font issue on the URL inside the accessURL element.

3.1. Approved auth. mech./Requirements

Change "Interfaces of type WebService..." to "Services that are registered with a VO registry as having a WebService type interface [VOResource]...."

5.1 Details of TLS-with-client-certificate/Requirements

I strongly recommend that the URIs that identify a security method use the form, ivo://ivoa.net/sso#method-name. As the authors know, every IVOA Identifier must resolve to a separate resource description. By using the pound delimiter, all of the method names can be defined within a single resource description.

Thus, change "ivo://ivoa.net/sso/tls-with-client-certificate" to "ivo://ivoa.net/sso#tls-with-client-certificate".

6.1 Details of TLS-with-password/Requirements

Change "ivo://ivoa.net/sso/tls-with-password" to "ivo://ivoa.net/sso#tls-with-password".

7.1 Details of digital signature

Requirements

Some indication that the elements referred to in the second paragraph are defined in WS-Security spec. I recommend the following edit:

"of type BinarySecurityToken (as defined in [WS-Security], section X.X)."

Section reference for the other terms would be a good idea.

Follow the term "trust anchor" with a reference to a document that defines this term.

Change "ivo://ivoa.net/sso/soap-digital-signature" to "ivo://ivoa.net/sso#soap-digital-signature".

Commentary

Section 8.2 gives a nice explanation of what is meant by a "trust anchor". However, as this i term is first introduced in section 7.1, it might be nice to either (1) provide brief explanatory remark here in section 7.2, or (2) provide a forward reference to section 8.2.

A trust anchor is a self-signed certificate that the application trusts as being authenticate. This is usually because the certificate was obtained by the application by a different channel (usually explicitly by the application's administrator) than the channel connecting the service and the client. See section 8.2 for more discussion of the role of a trust anchor in the chain of trust.

Please add a comment explaining what a "suitable SecurityTokenReference " would be.

8.2 Certificae chains

Requirements

Second paragraph: Follow the term "trust anchor" with a reference to a document that defines this term.

Commentary

The NVO certificate issuing services are capable of issuing short-term EECs. The rationale is that this opens up its use by a wider set of applications because it does not require the application to support proxy certificate chains [RFC3820]. That way only those applications that need to support delegation need to support this extra standard. As a result, I would recommend softening the language describing the role of EECs and proxies. Here's how I recommend you do this:

• "by CAs and are "permanent" to "by CAs and are often "permanent"--that is, they have a long lifetime"

• "Proxy certificates are short-term" to "Proxy certificates are usually short-term"

• Insert two new paragraph after the first one:

Proxy certificates are often used to solve two problems. The first is that a user may authenticate herself using a long lived EEC; however, it would not be safe to allow an application to have long-term use of that certificate, particularly if that application is remote. To solve this, a short-lived proxy certificate can be provided to the application to limit its privileges. Note that in some authentication models, the user can authenticate with a delegation service which can provide the application with a certificate. This can be either a short-lived proxy or a short-lived EEC; either will solve the problem.

The other problem is that one service requiring authentication will need to call another service requiring authentication. Solving this problem in the IVOA SSO framework requires the use of proxy certificates. Below is a scenario for how this can be accomplished.