Mass Move

Greg-

I've made modifications and uploaded a new version for your review before pubications and to make into a pdf.

Comments have been addressed by me as the document editor. I am asking for a final review and endorsement by co-authors by Friday Oct. 22,2004 (see 
mail to the authz-wg list). If no problems are found I would release the document for final GFSG review after this date.  

The attached document has change-tracking enabled so my modifications are easily visible. Detailed discussion of changes will take place on the 
mailing list.

Markus

(Updating status to indicate we are awaiting author action.  gbn)

Author needs to apply some edits to this document before it can go into final GFSG review. New version of the document will be uploaded shortly.

Olle,
You'll have to shepherd this since I'm an author.
AD's comment is expected to document concurrance publicly.
Dane

User removed

Comments on AuthZ Framework

Page 5: 2nd paragraph: "bases" should be "basis"

In the first paragraph of section 2, can the authors better differentiate this document from the other work? Why don't these other documents suffice 
in place of the GGF document? I'd like to see a stronger statement than "[these works] have influenced our framework."

Re: the definitions on p.6: The document defines "subject", "resource", and "authority", but these definitions are disclaimed with " This terminology 
will be more refined during the course of the document." Can't these terms be defined just once, completely?

The document consistently misuses "i.e.," as "i.e." and "e.g., " as "e.g."

The document defines an Authority as "An administrative entity that is capable of and authoritative for issuing, validating and revoking an electronic
 means of proof such that the named subject (a.k.a. holder) of the issued electronic means is authorized to exercise a certain right or assert a 
certain attribute." I am particularly uncomfortable with the phrase "electronic means of proof", which is awkward at the least. Can "means of proof" 
be replaced with "assertion" (which the document freely uses in the next paragraph)?

The document never actually states that the general procedure re: authorization (e.g.,is first to authenticate and then to authorize. That is, 
authentication is a NECESSARY first step. Why does the document not mention this? The authors imply (e.g., in the "three distinct processes" 
enumeration at the bottom of p. 6) that this is authenticate-then-authorize is not true. Can't this be simply stated in the document?

In this "three-distinct processes", can "executable policy" be replaced by the phrase "digital representation of the policy"? The policy itself is not
 "executable". Policy engines may interpret it,  but it is not "executable". 

Middle page 7, part c is currently "The signing of a record of an Authorization as to assert its authority." I don't know what this means. 

I don't know if I agree with the document's mapping of RFC2904 to the document's terminology. Specifically, the document states that the RFC2904 "AAA 
Server" is "a server acting on behalf of the Authorization Authority". For one thing, the AAA Server could be precisely the Authorization Authority, 
not acting on behalf of it. For another, the AAA server could be focused on Accounting, which has nothing to do with Authorization.

Top of page 9, in the description of the authorization push sequence, the document contains " This assertion should have a validity time window 
associated with it." Isn't this being prescriptive, and as such is out of the scope of the document? That is, what is the implied meaning of "should"?
 

p.17: " Some of the issues that are addressed by policy management is who can create�" should be " Some of the issues that are addressed by policy 
management are who"

Overall, it's a nice document, although it's redundant at times. I suspect that this is because separate individuals were assigned separate sections. 
Perhaps the editor of this document (Lorch) can go through and compress the redundant parts? Perhaps he believes he has already done this?

Finally, Section 6 ("related standards") could be improved by, instead of simply enumerating the related work such as SAML and XACML, the related work
 should be described as fitting into a particular place in Figure 3.1, which is the "generic" AuthZ architecture in this GGF document.

I am an author for this document and will have to recuse myself from GFSG review.

Added references based on Mary Thompson's comments

I have contributed to this document and I have participated in the editing and review.  I agree with the contents of this document and I endorse it.

Rich Baker