Apologies for the long delay in responding. These comments are appreciated, but I only recently became aware of their 
existence. My response are embedded below. - Von

<quote>
The initiator is attempting to invoke an operation, but the policy has time 
 or other constraints in it, that limit when or how the initiator may invoke 
 the operation - e.g., only 
between the hours of 8am and 5pm, or only up to a maximum of six times a day. 
 (Pg 5) 
 
[]Geographical location of the user might also be stated as one of the constraints. 
 (When or how or from where). 
</quote>

**** I don't have any fundamental objection to adding this as an example, but I don't now of any method in OGSA for 
determining or expressing the physical location of entities.

 <quote>
When we say when or how, I feel there is a feeling that the user will be able 
 access during that time or so many times for a considerably long period of 
 time. But what if the nature of permission is such that its short-lived, say 
 sporadic few-hours in 10 years. This is focused more towards the management 
 of authorizations  by the Authorization Service. 
Support for common OGSI actions: Operation and service data access on Grid Services 
 will be common. It is expected that a large amount of policy for OGSI can be 
 written regarding initiators rights to perform these actions. (Pg 6) 
 
[] I see this also as different types of policies exhibiting different levels 
 of granularity. 
</quote>

**** I don't disagree with this statement. Do you believe the document needs to be changed in some way?

 
 <quote>
Supporting Credentials: Queries to authorization services may need to supply 
 assertions about the initiator necessary for the decision-making process. 
 Alternatively, the authorization service may know how to retrieve the supporting 
 credentials itself, in which case the initiator may need to provide no information 
 or simply a pointer to where the information can be obtained. (Pg 6) 
 
[]Should the user authenticate to the Authorization service before submitting 
 "AUTHORIZATION DECISION REQUEST" to the authorization service or 
 should the authentication be a part of the request. We dont want someone requesting 
 on others behalf. I guess this is related to the push mode. 
</quote>

**** I agree that authorization services should have some notion of policy in regards to whom can request policy 
decisions. How about added a new bullet to this section (section 5):

 * Access Control to Authorization Decisions: For reasons of security and privacy, authorization services should be 
capable of enforcing access control on who can request authorization decisions. In the simplest incarnation, 
authorization services should be configurable so that they only answer queries from a set of trusted target resources. 
More complex implementations could allow for finer-grained policy based on the initiator and request. Some 
implementations may even want to require proof of that an initiator requested an action in order to authorize it.

<quote> 
Please note that these comments have been made with the intension of pariticipating 
 in such discussions and to learn more. 
</quote>

**** Thank you for your comments.