My apologies for missing the call. I was on a GFSG call. I had planned to use Skype, so perhaps I wouldn't have been successful calling in. A couple of comments on the proposed AVS for Globus: 1.Validation of Identity assertion. Checking that a DN belongs to a public key and is trusted up to CA trust root. David said this code should already exist in the PKI world .... Certainly, in open source and commercial products. You should think about if you need to support things like cross-certification; bridge CAs; or special EKUs, before picking a tool. How these things are handled can vary. 3.Authorisation assertion validation. Again Trust roots need to be configured in, to say who is trusted to assign which privileges to which groups of users. David said that he thought that the only difference between 2. and 3. was in the granularity, and that if a role (or attribute) only gave a single permission, then 2. could be used and there was no requirement for 3. I may not have the complete context here, but seems to me there may be an important difference in some environments. The policy for controlling the assignment of permissions based on roles may not be available at the site where an authorisation assertion is validated and consumed. In such cases, the role needs to validated and an authorisation assertion generated even if they have a 1:1 mapping. Finally we discussed the implications of carrying attributes and credentials within the same protocol.... The group did not see a problem in this. Thus it is left to Blair to raise his concerns on the list, since he raised the issue originally. My earlier comments were made to encourage discussion of the potential impact of these design decisions on implementers. I still believe its healthy to have that discussion during the design process. I am not arguing that the approach of carrying credentials as attribute types is wrong or can't be implemented, just that it has some impacts that should be considered. For example: - There is an already standardized, and implemented, approach to encoding credentials in SOAP messages as security tokens (UsernameToken, BinarySecurityToken, saml:Assertion, ...). I believe the proposal is to standardize a new set of SAML attribute type identifiers that define yet another way of encoding these credential types in XML. That means if we're sending an authenticated SOAP message using this mechanism, the implementation must support two code paths for serializing/de-serializing each possible credential type. Perhaps not a big deal, but it adds some complexity and long-term support costs. - If real attributes and credentials are both passed as an 'attribute' encoding, it impacts error handling. The code responsible for attribute decoding will need to handle both errors in initial attribute decoding as well as problems that may arise in trying to decode and validate a received credential. - Compliant implementations would need to properly handle all legal attribute types (real attributes or credentials), even if the service doesn't accept and process credentials. Again, some impact on potential failure modes and error handling. Perhaps others that are actually thinking about implementations can add to these. Its good to make a conscious decision that the benefits of the proposed design outweigh such considerations. I should also point out that while I am interested in this subject, my work and broader OGF commitments are leaving me little time to actually think about it. So, not sure how much I can contribute in the near term. Regards, Blair -----Original Message----- From: ogsa-authz-wg-bounces@ogf.org [mailto:ogsa-authz-wg-bounces@ogf.org] On Behalf Of David Chadwick Sent: Wednesday, February 14, 2007 4:28 AM To: OGSA AUTHZ WG Subject: [OGSA-AUTHZ] minutes of yesterdays telecon Are now on the grid forum at http://forge.gridforum.org/sf/go/doc14236?nav=1 regards David -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** -- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg