Comments on "Use of SAML for OGSA AUthorization"
Here is my set of comments. Dane *** Substantive Issues *** Section 6.a.ii Element <SubjectAttributeReferenceAdvice> The schema fragment indicates an unbounded maxOccurs of element AttributeDesignator. Does the error response for a receiver overflow need to be specified or is this inherited from the SAML (or unnecessary since it's an advice element) ? Section 6.b, attribute Recipient The specification states the requirements for this attribute when the initiating ExtendedAuthorizationDecisionQuery contains a Recipient attribute, but does not state requirements when the initiating ExtendedAuthorizationDecisionQuery does not. Is it "MAY" or "SHOULD NOT" in that case? Section 7.a (Extended) AuthorizationDecisionQuery The "client MUST" at the beginning of this section seems to me to proclude the possibility of a client giving blanket authorization for some action (say the equiv of reading a webpage). Should the section rather start "An OGSA client SHOULD request an authorization decision. A client requesting an authorization decision MUST do so using either ..." ? Section 7.a X.509 Proxy Certificate Format Identifier Reference [ProxyCerts] seems to me should point to RFC 3820 and be normative. What is the reason to reference (only) the workshop paper ? Section 7.a.2.i SubjectConfirmation Element The condition "authenticated using the Grid Security Infrastructure" would seem to me to require a normative reference in a normative section. Is there a normative reference available or should this be defined here ? Section 7.a.2.ii.1 Grid Services The condition "is a Grid service" would seem to me to require a normative reference in a normative section. Is there a normative reference available or should this be defined here ? Section 7.a.2.ii.2 Wildcard Resource Bullet 1 under this section states the desire to be "to learn the subject's rights on all the resources of which the authorization service is aware." This seems like an unbounded desire and not the obligation we wish to imply on the authorization service. Should this rather be "all resources for which the authorization service believes itself to be authoritative" ? Section 8.c Full WSDL This section shows WSDL to create an "OGSI SAML Grid Authorization Service". However, this doc is about using SAML for OGSA authorization. This rather read "OGSA SAML ..." ? I would suggest that Section 17 was a useful primer for discussion/creation of this document, but should be removed from the final form of this specification document (keep them clean). It would be nice to capture this text as a working document in the WG as a short background summary. Implementers with questions (ie. the primary audience for this document) about SAML should be referred to the normative SAML docs. *** Editorial comments *** The "ogsa-saml" XML namespace isn't at the URI listed. Is this a chicken and the egg problem or a problem with the website ? (there are others as well inside the doc) Section 4, paragraph 2, sentence 1, should read "... and it is upon this version of SAML ..." Section 5a, subbullet 1, sentence 3, should read "... if all actions were allowed or ..." Section 6.a, attribute RequestedSigned, sentence 2: should this read " This element SHOULD contain the QName..." ? Section 6.b, element "Recipient" Should this element me tagged "[Optional]" with the explanitory text below or is the convention to leave such conditionals untagged ? Section 6.b, paragraph 3 has a spelling error for <SimpleAuthorizationDecisionStatement> (missing the 3rd "i") Section 7, paragraph 1, sentence 2, should read "... used to meet OGSA requirements ..." (transposition) Section 7.a.2 Should the phrase "domain of resources" be defined ? <Is this defined in the AuthZ glossary ?> Section 7.a.4 Should the list of things an Evidence element may contain be enumerated as a list itself or left inline (I found referents tough to determine clearly). Section 7.a.2.i The editor's note on X509PKiPathv1 remains. This needs to be resolved and removed. Section 7.a.2.ii Resource String Should this sentence begin rather "The Resource string MUST be "*" ... " ? Section 7.a.2.iii.2 Grid Service Data Access There seems a number mismatch in sentence 1. Should it read rather "... (SDEs) associated with a Grid Service ..." Section 7.a.2.iii.2 (various places) Should the text read rather "The action string SHOULD contain the QName..." Section 7.b.i Conditions Element, Paragraph 2, sentence 3 should read "... using, for example, elements of XACML." (I'm not sure if the section numbering change is an artifact of my OpenOffice or the .doc) Section 7.b.iii AuthorizationDecisionStatement Element, paragraph 2 should read "... render a decision due to ..." Section 7.b.iv AttributeStatement Element should expand the RBAC acronym (first use) Section 7.b.v Signature Element should read "... places no constraints on ..." Section 8.a.ii supportsIndeterminate should read "... may not allow the return of indeterminate."
Dane, Thank you for your comments. Responses to your remarks are inline below. Most were accepted, a few I've argued back on. I'm not sure what happened, but your section numbers are screwed up. Looks like an OpenOffice snafu. Major section number is one off and subsections are converted from normal numerals to roman and letters and subtimes shifted. I think I've correctly transformed them to correct section and have indicated actual section numbers for substantial comments. We seem to disagree on what consitutes a normative reference. My view is that it is one that is essential to understanding the document at hand. To this end, references regarding, e.g., proxy certificates are not normative. Von dane@fnal.gov writes (11:57 January 3, 2005):
Here is my set of comments. Dane
*** Substantive Issues ***
Section 6.a.ii Element <SubjectAttributeReferenceAdvice> The schema fragment indicates an unbounded maxOccurs of element AttributeDesignator. Does the error response for a receiver overflow need to be specified or is this inherited from the SAML (or unnecessary since it's an advice element) ?
(Section 5.1.2) Since understanding of these elemenets is not required, I would say a recipient that was unable to process some number of them for any reason could safely ignore them. So I do not believe specification of an error is required.
Section 6.b, attribute Recipient The specification states the requirements for this attribute when the initiating ExtendedAuthorizationDecisionQuery contains a Recipient attribute, but does not state requirements when the initiating ExtendedAuthorizationDecisionQuery does not. Is it "MAY" or "SHOULD NOT" in that case?
(5.2) Since Recipient is deprecated, this is a SHOULD NOT.
Section 7.a (Extended) AuthorizationDecisionQuery The "client MUST" at the beginning of this section seems to me to proclude the possibility of a client giving blanket authorization for some action (say the equiv of reading a webpage). Should the section rather start "An OGSA client SHOULD request an authorization decision. A client requesting an authorization decision MUST do so using either ..." ?
(6.1) What this sentence is trying to say, is that a client *requesting an authorization decision* MUST use either an AuthorizationDecisionQuery or an ExtendedAuthorizationDecisionQuery. I've reworded it to clarify.
Section 7.a X.509 Proxy Certificate Format Identifier Reference [ProxyCerts] seems to me should point to RFC 3820 and be normative. What is the reason to reference (only) the workshop paper ?
(6.1) I corrected this to reference RFC 3820. I left this as informational as I do not believe an understanding of proxy certificates is necessary to understand this document.
Section 7.a.2.i SubjectConfirmation Element The condition "authenticated using the Grid Security Infrastructure" would seem to me to require a normative reference in a normative section. Is there a normative reference available or should this be defined here ?
(6.1.2) I've struck the phrase "use the Grid Security Infrastructure" as I do not believe it adds anything to the text. Authenticated via Proxy Certificate is sufficent. I added references to RFC 3280 and RFC 3820. But informational, as again, I don't see understanding of these RFCs as critical to undertstanding this draft.
Section 7.a.2.ii.1 Grid Services The condition "is a Grid service" would seem to me to require a normative reference in a normative section. Is there a normative reference available or should this be defined here ?
(6.1.3.1) There is a normative reference to [OGSI] at the end of the sentence. I believe this is sufficent.
Section 7.a.2.ii.2 Wildcard Resource Bullet 1 under this section states the desire to be "to learn the subject's rights on all the resources of which the authorization service is aware." This seems like an unbounded desire and not the obligation we wish to imply on the authorization service. Should this rather be "all resources for which the authorization service believes itself to be authoritative" ?
(6.1.3.2) Agreed. Change made.
Section 8.c Full WSDL This section shows WSDL to create an "OGSI SAML Grid Authorization Service". However, this doc is about using SAML for OGSA authorization. This rather read "OGSA SAML ..." ?
(7.3) Agreed. Corrected.
I would suggest that Section 17 was a useful primer for discussion/creation of this document, but should be removed from the final form of this specification document (keep them clean). It would be nice to capture this text as a working document in the WG as a short background summary. Implementers with questions (ie. the primary audience for this document) about SAML should be referred to the normative SAML docs.
(Appendix A) I agree. I have removed this appendix.
*** Editorial comments ***
The "ogsa-saml" XML namespace isn't at the URI listed. Is this a chicken and the egg problem or a problem with the website ? (there are others as well inside the doc)
URI are not URLs. They do not necessarily resolve. In this case the URI is purely a unique identifier (like an OID).
Section 4, paragraph 2, sentence 1, should read "... and it is upon this version of SAML ..."
OK
Section 5a, subbullet 1, sentence 3, should read "... if all actions were allowed or ..."
OK
Section 6.a, attribute RequestedSigned, sentence 2: should this read " This element SHOULD contain the QName..." ?
Actually, I believe it is a MUST.
Section 6.b, element "Recipient" Should this element me tagged "[Optional]" with the explanitory text below or is the convention to leave such conditionals untagged ?
Tagged.
Section 6.b, paragraph 3 has a spelling error for <SimpleAuthorizationDecisionStatement> (missing the 3rd "i")
OK.
Section 7, paragraph 1, sentence 2, should read "... used to meet OGSA requirements ..." (transposition)
I'm staring at the sentence and it seems to read what you already suggest.
Section 7.a.2 Should the phrase "domain of resources" be defined ? <Is this defined in the AuthZ glossary ?>
We're not trying to change anything with this text, just summarize its purpose. I've changed it to "resource or resources" which I believe gets the point across without undue complication.
Section 7.a.4 Should the list of things an Evidence element may contain be enumerated as a list itself or left inline (I found referents tough to determine clearly).
I struck the environmental parameters since this is not longer specified in this document and added a sentence explaining the ReferenceStatement element. I think this clarifies the text.
Section 7.a.2.i The editor's note on X509PKiPathv1 remains. This needs to be resolved and removed.
Yes. I'm not online, will resolve when I am.
Section 7.a.2.ii Resource String Should this sentence begin rather "The Resource string MUST be "*" ... " ?
Yes.
Section 7.a.2.iii.2 Grid Service Data Access There seems a number mismatch in sentence 1. Should it read rather "... (SDEs) associated with a Grid Service ..."
Yes.
Section 7.a.2.iii.2 (various places) Should the text read rather "The action string SHOULD contain the QName..."
Actually I believe this should be MUST's and have changed them accordingly.
Section 7.b.i Conditions Element, Paragraph 2, sentence 3 should read "... using, for example, elements of XACML."
OK
(I'm not sure if the section numbering change is an artifact of my OpenOffice or the .doc)
Ah-ha! :-)
Section 7.b.iii AuthorizationDecisionStatement Element, paragraph 2 should read "... render a decision due to ..."
OK
Section 7.b.iv AttributeStatement Element should expand the RBAC acronym (first use)
OK
Section 7.b.v Signature Element should read "... places no constraints on ..."
OK
Section 8.a.ii supportsIndeterminate should read "... may not allow the return of indeterminate."
OK -END Comments-
I worked with Word (this time) since I was sensitive to the possibility compatibility problems. Maybe a Mac/PC issue (or my faulty memory). I'll see if I can reproduce the problem. I would agree to that definition of a normative reference. I'll have to get back to you on whether it's essential after reading your responses. I believe I was asking for normative references in places where they were needed to evaluate a conditional in a normative part of the spec. Dane On Jan 12, 2005, at 5:48 PM, Von Welch wrote:
Dane,
Thank you for your comments. Responses to your remarks are inline below. Most were accepted, a few I've argued back on.
I'm not sure what happened, but your section numbers are screwed up. Looks like an OpenOffice snafu. Major section number is one off and subsections are converted from normal numerals to roman and letters and subtimes shifted. I think I've correctly transformed them to correct section and have indicated actual section numbers for substantial comments.
We seem to disagree on what consitutes a normative reference. My view is that it is one that is essential to understanding the document at hand. To this end, references regarding, e.g., proxy certificates are not normative.
Von
dane@fnal.gov writes (11:57 January 3, 2005):
Here is my set of comments. Dane
*** Substantive Issues ***
Section 6.a.ii Element <SubjectAttributeReferenceAdvice> The schema fragment indicates an unbounded maxOccurs of element AttributeDesignator. Does the error response for a receiver overflow need to be specified or is this inherited from the SAML (or unnecessary since it's an advice element) ?
(Section 5.1.2) Since understanding of these elemenets is not required, I would say a recipient that was unable to process some number of them for any reason could safely ignore them. So I do not believe specification of an error is required.
Section 6.b, attribute Recipient The specification states the requirements for this attribute when the initiating ExtendedAuthorizationDecisionQuery contains a Recipient attribute, but does not state requirements when the initiating ExtendedAuthorizationDecisionQuery does not. Is it "MAY" or "SHOULD NOT" in that case?
(5.2) Since Recipient is deprecated, this is a SHOULD NOT.
Section 7.a (Extended) AuthorizationDecisionQuery The "client MUST" at the beginning of this section seems to me to proclude the possibility of a client giving blanket authorization for some action (say the equiv of reading a webpage). Should the section rather start "An OGSA client SHOULD request an authorization decision. A client requesting an authorization decision MUST do so using either ..." ?
(6.1) What this sentence is trying to say, is that a client *requesting an authorization decision* MUST use either an AuthorizationDecisionQuery or an ExtendedAuthorizationDecisionQuery. I've reworded it to clarify.
Section 7.a X.509 Proxy Certificate Format Identifier Reference [ProxyCerts] seems to me should point to RFC 3820 and be normative. What is the reason to reference (only) the workshop paper ?
(6.1) I corrected this to reference RFC 3820.
I left this as informational as I do not believe an understanding of proxy certificates is necessary to understand this document.
Section 7.a.2.i SubjectConfirmation Element The condition "authenticated using the Grid Security Infrastructure" would seem to me to require a normative reference in a normative section. Is there a normative reference available or should this be defined here ?
(6.1.2) I've struck the phrase "use the Grid Security Infrastructure" as I do not believe it adds anything to the text. Authenticated via Proxy Certificate is sufficent.
I added references to RFC 3280 and RFC 3820. But informational, as again, I don't see understanding of these RFCs as critical to undertstanding this draft.
Section 7.a.2.ii.1 Grid Services The condition "is a Grid service" would seem to me to require a normative reference in a normative section. Is there a normative reference available or should this be defined here ?
(6.1.3.1) There is a normative reference to [OGSI] at the end of the sentence. I believe this is sufficent.
Section 7.a.2.ii.2 Wildcard Resource Bullet 1 under this section states the desire to be "to learn the subject's rights on all the resources of which the authorization service is aware." This seems like an unbounded desire and not the obligation we wish to imply on the authorization service. Should this rather be "all resources for which the authorization service believes itself to be authoritative" ?
(6.1.3.2) Agreed. Change made.
Section 8.c Full WSDL This section shows WSDL to create an "OGSI SAML Grid Authorization Service". However, this doc is about using SAML for OGSA authorization. This rather read "OGSA SAML ..." ?
(7.3) Agreed. Corrected.
I would suggest that Section 17 was a useful primer for discussion/creation of this document, but should be removed from the final form of this specification document (keep them clean). It would be nice to capture this text as a working document in the WG as a short background summary. Implementers with questions (ie. the primary audience for this document) about SAML should be referred to the normative SAML docs.
(Appendix A) I agree. I have removed this appendix.
*** Editorial comments ***
The "ogsa-saml" XML namespace isn't at the URI listed. Is this a chicken and the egg problem or a problem with the website ? (there are others as well inside the doc)
URI are not URLs. They do not necessarily resolve. In this case the URI is purely a unique identifier (like an OID).
Section 4, paragraph 2, sentence 1, should read "... and it is upon this version of SAML ..."
OK
Section 5a, subbullet 1, sentence 3, should read "... if all actions were allowed or ..."
OK
Section 6.a, attribute RequestedSigned, sentence 2: should this read " This element SHOULD contain the QName..." ?
Actually, I believe it is a MUST.
Section 6.b, element "Recipient" Should this element me tagged "[Optional]" with the explanitory text below or is the convention to leave such conditionals untagged ?
Tagged.
Section 6.b, paragraph 3 has a spelling error for <SimpleAuthorizationDecisionStatement> (missing the 3rd "i")
OK.
Section 7, paragraph 1, sentence 2, should read "... used to meet OGSA requirements ..." (transposition)
I'm staring at the sentence and it seems to read what you already suggest.
Section 7.a.2 Should the phrase "domain of resources" be defined ? <Is this defined in the AuthZ glossary ?>
We're not trying to change anything with this text, just summarize its purpose. I've changed it to "resource or resources" which I believe gets the point across without undue complication.
Section 7.a.4 Should the list of things an Evidence element may contain be enumerated as a list itself or left inline (I found referents tough to determine clearly).
I struck the environmental parameters since this is not longer specified in this document and added a sentence explaining the ReferenceStatement element. I think this clarifies the text.
Section 7.a.2.i The editor's note on X509PKiPathv1 remains. This needs to be resolved and removed.
Yes. I'm not online, will resolve when I am.
Section 7.a.2.ii Resource String Should this sentence begin rather "The Resource string MUST be "*" ... " ?
Yes.
Section 7.a.2.iii.2 Grid Service Data Access There seems a number mismatch in sentence 1. Should it read rather "... (SDEs) associated with a Grid Service ..."
Yes.
Section 7.a.2.iii.2 (various places) Should the text read rather "The action string SHOULD contain the QName..."
Actually I believe this should be MUST's and have changed them accordingly.
Section 7.b.i Conditions Element, Paragraph 2, sentence 3 should read "... using, for example, elements of XACML."
OK
(I'm not sure if the section numbering change is an artifact of my OpenOffice or the .doc)
Ah-ha! :-)
Section 7.b.iii AuthorizationDecisionStatement Element, paragraph 2 should read "... render a decision due to ..."
OK
Section 7.b.iv AttributeStatement Element should expand the RBAC acronym (first use)
OK
Section 7.b.v Signature Element should read "... places no constraints on ..."
OK
Section 8.a.ii supportsIndeterminate should read "... may not allow the return of indeterminate."
OK
-END Comments-
I agree with your responses and close all my comments save the following items : On Jan 12, 2005, at 5:48 PM, Von Welch wrote:
*** Editorial comments ***
The "ogsa-saml" XML namespace isn't at the URI listed. Is this a chicken and the egg problem or a problem with the website ? (there are others as well inside the doc)
URI are not URLs. They do not necessarily resolve. In this case the URI is purely a unique identifier (like an OID).
I'm confused: doesn't the namespace document need to be publicly available ? If it's not available by resolving the URI, where should it be ? Anyway, my main concern was whether we'd uncovered a problem with the GGF webpages missing some documents that should be there now.
Section 7, paragraph 1, sentence 2, should read "... used to meet OGSA requirements ..." (transposition)
I'm staring at the sentence and it seems to read what you already suggest.
In the copy I'm looking at, it says "OSGA" not "OGSA". Dane
Dane, Responses inline below. Latest version of the document is now at the first URL below. I believe this document is now ready to proceed along with the attribute document at the second URL. https://forge.gridforum.org/docman2/ViewProperties.php?group_id=119&category_id=450&document_content_id=3292 https://forge.gridforum.org/docman2/ViewProperties.php?group_id=119&category_id=451&document_content_id=2818 Von Dane Skow writes (17:20 January 14, 2005):
I agree with your responses and close all my comments save the following items :
On Jan 12, 2005, at 5:48 PM, Von Welch wrote:
*** Editorial comments ***
The "ogsa-saml" XML namespace isn't at the URI listed. Is this a chicken and the egg problem or a problem with the website ? (there are others as well inside the doc)
URI are not URLs. They do not necessarily resolve. In this case the URI is purely a unique identifier (like an OID).
I'm confused: doesn't the namespace document need to be publicly available ? If it's not available by resolving the URI, where should it be ?
It's not a namespace document. It's a namespace identifier. All this URI does is uniquely scope the names that follow, it happens to look like a URL, but that is where the resemblance ends. Think of a URI as equivalent to an OID, but it leverages DNS namespaces such that there doesn't have to be a top-level registry.
Anyway, my main concern was whether we'd uncovered a problem with the GGF webpages missing some documents that should be there now.
Section 7, paragraph 1, sentence 2, should read "... used to meet OGSA requirements ..." (transposition)
I'm staring at the sentence and it seems to read what you already suggest.
In the copy I'm looking at, it says "OSGA" not "OGSA".
Fixed.
participants (3)
-
Dane Skow -
dane＠fnal.gov
-
Von Welch