Credential Delegation Protocol specification: Request for Comments

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

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.

• 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.

• 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.

Comments by TCG

During the TCG review, chairs should add their comments under their name