Public comments are a very important part of the OGF document approval process. Through public comments, documents are given scrutiny by people with a wide range of expertise and interests. Ideally, a OGF document will be self-contained, relying only on the other documents and standards it cites to be clear and useful. Public comments of any type are welcomed, from small editorial comments to broader comments about the scope or merit of the proposed document. The simple act of reading a document and providing a public comment that you read it and found it suitable for publication is very useful, and provides valuable feedback to the document authors.
Thank you for making public comments on this document!
Comments for Document: Functional Components of Grid Service Provider Authorisation Service Middleware
| Author(s): | D. Chadwick |
| Type: | INFO |
| Area: | Security |
| Group: | OGSA-Authz-WG |
| Public Comment End: | 5 Oct, 2008 |
Comments:
Posted by: dwchadwick 2008-11-01 05:37:47OK
I think this document is OK to publish now, subject to a couple of minor amendments to its definitions, as follows
i) add "about entities" to the end of the definition of CIS
ii) Insert a new definition for Identity Provider as follows "Identity Provider – is a type of Credential Issuing Service that is a combined Attribute Authority and Authentication Service that can authenticate users and provide attribute assertions about them."
i) add "about entities" to the end of the definition of CIS
ii) Insert a new definition for Identity Provider as follows "Identity Provider – is a type of Credential Issuing Service that is a combined Attribute Authority and Authentication Service that can authenticate users and provide attribute assertions about them."
Posted by: rosinnott 2008-11-01 10:09:32Comments from Rich Sinnott
A few comments from me below (apologies for delay but usual excuses of lots of work apply - missing OGFs is also a big factor). I have numbered them for clarity and note that none of them are showstoppers.
1. "Attribute Release Policy. A policy held by a Credential Issuing Service that says who should be allowed to request attribute assertions about whom." I guess the ARP could/should be which attributes are released to whom (if we are working in push mode).
2. "Some CISs (such as credit card issuers) may only issue credentials to their rightful holders; others (such as the Shibboleth AA) may issue them to trusted SPs" - I don't think "issue" in "issue them to trusted SPs" is the right word. A CIS issues credentials to subjects/users - it releases them to SPs. No? Should it not be "release them to trusted SPs"?
3. "Unacceptable credentials are ignored by the SP." I guess this depends. An SP may want to log which credentials are being passed by whom to check against attacks etc.
4. I'm not sure if sequential numbering is needed in Figures 1-4 to show information flow. Probably not.
Rest is fine for me... thanks for attribution. Not sure I deserved it - but maybe now.
Cheers,
Rich
5.
1. "Attribute Release Policy. A policy held by a Credential Issuing Service that says who should be allowed to request attribute assertions about whom." I guess the ARP could/should be which attributes are released to whom (if we are working in push mode).
2. "Some CISs (such as credit card issuers) may only issue credentials to their rightful holders; others (such as the Shibboleth AA) may issue them to trusted SPs" - I don't think "issue" in "issue them to trusted SPs" is the right word. A CIS issues credentials to subjects/users - it releases them to SPs. No? Should it not be "release them to trusted SPs"?
3. "Unacceptable credentials are ignored by the SP." I guess this depends. An SP may want to log which credentials are being passed by whom to check against attacks etc.
4. I'm not sure if sequential numbering is needed in Figures 1-4 to show information flow. Probably not.
Rest is fine for me... thanks for attribution. Not sure I deserved it - but maybe now.
Cheers,
Rich
5.
login
RSS