Credential Delegation Protocol specification: Request for Comments

This document will act as RFC centre for the Credential Delegation Protocol specification Proposed Recommendation v1.0.

Review period: 2008 September 26 – 2008 October 24

In order to add a comment to the document, please edit this page and add your comment to the list below (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussions about any of the comments or responses should be conducted on the GWS mailing list, grid@ivoa.net.

Comments from the community

• Sample comment by JoeBloggs
  • Response (by AloysiusBickerstaffe)

RayPlante

• Please adjust the paragraph formatting to put space between paragaphs; it's difficult to read without this space.

• 2nd to last paragraph of section 1: I think the subjects these sentences are perhaps incorrect; I think what is meant instead is...

In IVOA protocols, a client must delegate credentials before calling a service that needs to use delegated credentials. The client can find out the need for delegation from the service registration.

• Section 2.1: In IVOA-speak, "resource" more commonly refers to things described in IVOA-compliant registries, rather than the more general Web notion of a resource that is intended in this document. I recommend adding a line or two in the introduction that defines what we mean by a "resource" in the context of this document. Something like:

The delegation process is enabled via a set of four service components that are each accessible via a URL which we refer to as web resources.

• Section 2.1.1: Since these resources are actually resolvable, I would, for greater clarity, refer to their handles as URLs rather than via the more general term of URI.

• Section 2.2.1, 2nd paragraph: "mean" to "means"

• It seems unclear as to for what purposes a Service Resource (in the Registry sense) may use delegated credentials once they are created; that is, there should be at least some semantic understanding that when the delegated credentials are created that they should only be used with a particular secured service rather than just any operation provided by the server. In particular, suppose a Service Resource supports two capabilities, each representing a secured service, plus a third representing the delegation service. Is it implicitly understood that the delegated credentials can then be used with either capability? If so, we should say so.

The delegation is supposed to be useable with any capability that is a sibling of the one in which the delegation endpoint is declared. Yes, we should make this explicit. We should also state more clearly that the delegation lasts until the use-by time written into the delegated proxy-certificate, and that there is no way to delegate powers for a single use. Further, we should point out that by delegating a basic proxy-certificate, the client allows the recipient to delegate that identity to other entities. This onward delegation can be ruled out sending a restricted proxy, and the restriction is defined by RFC 3820, not by our protocol; but we should point out what needs to be done and why it might be desirable. -- GuyRixon - 20 Oct 2008

• How does a client tell that delegation is needed? Is it simply from the presence of the Delegation capability? Given that there might be multiple capabilities and multiple interfaces, a stronger indicator is needed. It seems to me that we should be making use of the VOResource element, <securityMethod> (a child of <interface>). This could provide an explicit marker of which interfaces require delegation.

I agree with your suggestion. Should this convention be made normative in the delegation-protocol document? Or is it just a suggestion, to be made normative in the standards covering the capability in which the annotation appears? -- GuyRixon - 20 Oct 2008

• In general, I found this document difficult to parse due in large part to the structure of "specification" followed by "commentary". (I believe I've expressed this before.) The specification section lays down technical requirements that seem largely devoid of semantics and motivation; thus, on first read, nothing stuck with me. It wasn't until the commentary section could I get a sense of what's really going on; then I had to go back to the specification section to actually digest its contents. A secondary barrier was the reference without further explanation to pre-existing standards (e.g. the various RFC documents). The following suggestions I think could make this document much clearer and more readable:
  • Combine the specification and commentary sections into one section in which:
    • The overall semantics/motivation of the specification is summarized at the beginning
    • recommendations from the "commentary" can be considered part of the normative text
    • non-normative comments can be set off in "Note" boxes (see Registry Interfaces or VOResource specs for examples).
  • Place more emphasis on the presentation on making clear how this works semantically.
  • Insert additional examples via example boxes
  • When an external standard is referenced, try to give some sense of what they define either by adding a clause that summarizes the standard, or by giving an example of its use. For example in section 2.2.1, an example of an encoded distinguished name would make looking up RFC 2253 unnecessary.

In general, I would be happy to offer suggested text for addressing any of the above.

OK, maybe you should be the editor for the final draft. Let's discuss this at the Baltimore meeting. -- GuyRixon - 20 Oct 2008

BobHanisch

I also had difficulty parsing this document, and agree with Ray's suggestions about changing the formatting and structure.

Not being an expert in this area, though, I wonder if the document is even necessary. It refers to a Globus and IETF specification as its basis. If this is a subset of those specifications, wouldn't it be easier just to say what subset it is? What is unique to this specification, and where does it diverge from existing practice in other standards? And why?

Can't we just say that IVOA Credential Delegation is handled in accord with IETF x.x, Globus whatever, with the following (hopefully short list of) restrictions and/or deviations?

29 Sept 2008

The relevant IETF standard is RFC3820 "Internet X.509 Public Key Infrastructure (PKI): Proxy Certificate Profile". It defines what is in the proxy certificates, not how to get one into the service of choice. The normative text concerning the format and content of the proxies in the document under review does as you ask: it refers to the RFC and details only the special use for IVOA.

Although our protocol is inspired by the Globus one, and uses the good ideas of the latter, it's a separate thing. Our protocol defines a REST service; the Globus one is a SOAP service. Our protocol does not require changes to the protocols (DAL etc.) which which it is mixed; the Globus one requires the addition of an extra parameters of those protocols. Our delegation protocol does not require elaborate authentication of the act of delegation itself; the Globus one requires authentication operations that are not standard either for IVOA or the rest of the Globus Toolkit. Basically, the Globus protocol wasn't suitable for IVOA so a new one was devised. It can't usefully be specified as a delta on the Globus standard.

If it is useful, I can list in the introduction that things that were found undesirable in the Globus delegation protocol and the motivations for designing our own.

-- GuyRixon - 20 Oct 2008

TCG Review (from 21/09/2009 to 16/10/2009)

During the TCG review, Working and Interest Group chairs should add their comments under their name:

Applications (Tom McGlynn, Mark Taylor)

Data Access Layer (Keith Noddle, Jesus Salgado)

Approved.

Data Model (Mireille Louys, Anita Richards)

Grid & Web Services (Matthew Graham, Paul Harrison)

This is a pile of hooey I approve this document. MatthewGraham

Registry (Ray Plante, Aurelien Stebe)

Approved. (RayPlante, I am a co-author.)

Semantics (Sebastien Derriere, Norman Gray)

A few acronyms should be made explicit the first time they are used (OU, CN). There does not seem to be any implication for the Semantic WG in this document, so nothing prevents approval. -- SebastienDerriere

VOEvent (Rob Seaman, Alasdair Allan)

No comments on the content (not obvious how this might be relevant to VOEvent). Formatting of the html included strange characters when displayed on Safari. - RobSeaman

VO Query Language (Pedro Osuna, Yuji Shirasaki)

No reason from the VOQL point of view to stop this document. I approve.

VOTable (FrancoisOchsenbein)

Having no expertise at all in this domain, I trust the writer and give my formal approval.

I have also problems viewing the HTML version mentioned by Bob Hanisch, which looks like a bad interpretation of UTF-8 vs ISO-8859-1 (non-breakeable space appears as uppercase A with a tilde) I guess creating a non-UTF8 HTML output document should solve the problem.

Standard and Processes (Francoise Genova)

I appreciate the authors' effort to write a clear document. Same remark as others about the need to check that all abbreviations are defined the first time they appear (e.g. TLA, CN). I approve the document, provided that it is systematically checked.

Astro RG (Masatoshi Ohishi)

I would like to suggest two issues:

(1) The authentication process is shown in text only. It would be very helpful if simple figure showing the command/request/reply sequence. This idea may apply to sections 2 and 3.

(2) There are several abbreviations, such as CN, DN, EEC, CSR, and others. It seems to be helpful if you add a new appendix to summarise such "jargons".

These will be added for clarification. -- MatthewGraham

Data Curation & Preservation (Bob Hanisch)

I have no particular comments on content at this point. I do note, however, that I had problems with viewing the document itself. The Word version came across with extraneous boxes, the HTML version displays with strange characters, and the PDF version displays properly for me only after I download it and display it locally. I wonder if anyone else sees similar problems.

Theory (Herve Wozniak, Claudio Gheller)

It is not obvious how the TIG could be impacted by this standard. Approved anyway.

TCG (Christophe Arviset, Severin Gaudet)

I approve the document. Note that for the readibility of the final version, it would be necessary to add page numbers to the document.

This will be done. -- MatthewGraham