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

[Dane Skow]

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