Dear WG the next telecon is scheduled for Wed 8 November. I believe that the "Functional Components of Grid Service Provider Authorisation Service Middleware" document is now complete. I would us like to confirm that we are broadly happy with this model at the telecon, and then move onto the more important work, which is to define the protocols/profiles necessary to implement this model. The latest document describes three interfaces that are candidates for standardisation, namely: 1. one for the context handler talking to the PEP, 2. a second for the context handler talking to the CVS and 3. a third for the context handler talking to the PDP. Each of these 3 interfaces could be APIs or open protocols. As specified in the Functional Components document, the functionality required of the three interfaces is as follows: 1. PEP-Context Handler. PEP→CH, the authenticated name of the user, the credentials of the user (optional) and the user’s access request. CH→PEP, the authorization decision. 2. Context Handler-CVS. CH→CVS, the authenticated name of the user, the credentials of the user (optional). CVS→CH, the validated attributes of the user. 3. Context Handler-PDP. CH→PDP, the authenticated name of the user, the validated attributes of the user and the user’s access request. PDP→CH, the authorization decision. I would like to make the following proposal for discussion at the next telecon. If credentials can be packaged as attributes, then only two protocols need to be standardised, namely 1/3 and 2. This is not so radical. It is already a feature of our existing SAML profile, and it has been successfully implemented by at least 4 implementations that I know of (GT, Permis, Primea, OMII(UK)). So I dont see any problem in this. Here is how it works. In XACML, an attribute is currently defined as an attribute ID, a data type and a value. The contents of all 3 are transparent to the protocol and are carried as XML strings. So essentially they can contain anything. When we package a credential as an attribute, we simply define a new attribute ID and data type to represent the credential and the value is then the string encoding of the credential. So to pass the following within the same protocol as attributes we do the following. 1. An Attribute, e.g. AT ID=role DT=string AV=student, sent as usual with no modifications <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string"> <AttributeValue>student</AttributeValue> </Attribute> 2. An X.509 attribute certificate credential in which AT ID=X.509AC DT=BER AV=<some BER>, AT is sent as <Attribute AttributeId="://www.ieft.org/rfc/rfc2256.txt# attributeCertificateAttribute" the value is base64 encoded into a string, and the DT is either string or Base64 string (if this exists) 3. A SAML Attribute Assertion credential AT ID=SAML Attribute Assertion DT=XML AV=<SAML AA XML>, we need to define an attribute ID for a SAML Attribute Assertion (unless this already exists), the DT is string, and then we send the value enclosed in speech marks " " 4. An X.509 Public Key certificate with Subject Directory Attributes credential. Send in the same way as an X.509 AC, except that ID is userCertificate. I should like the above to form a major topic for discussion at the telecon. If we can agree on this, it makes the standardisation work 30% easier!! 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://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************