[OGSA-AUTHZ] minutes of yesterdays telecon

[Blair Dillaway]

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 at ogf.org [mailto:ogsa-authz-wg-bounces at 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 at 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 at ogf.org
  http://www.ogf.org/mailman/listinfo/ogsa-authz-wg