[OGSA-AUTHZ] Comments on "Use of SAML for OGSA AUthorization"

[Von Welch]

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 at 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-