Credential Delegation Protocol specification: Request for CommentsThis 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
RayPlante
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.
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.
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > | 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 | |||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < | In general, I would be happy to offer suggested text for addressing any of the above. | |||||||
> > | In general, I would be happy to offer suggested text for addressing any of the above. | |||||||
Added: | ||||||||
> > | OK, maybe you should be the editor for the final draft. Let's discuss this at the Baltimore meeting. -- GuyRixon - 20 Oct 2008 | |||||||
BobHanischI 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 | ||||||||
Changed: | ||||||||
< < | 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 does as you ask: it refers to the RFC and details only the special use for IVOA. | |||||||
> > | 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
Comments by TCGDuring the TCG review, chairs should add their comments under their name<--
<--
|